[A11Y-11106] Implement SIA-R118.

[pooya-si]

Description

Implement SIA-R118.

Jira Ticket

A11Y-11106

Related Documentation

https://www.w3.org/TR/WCAG2/#images-of-text
https://github.com/Siteimprove/sanshikan/blob/main/rules/sia-r118.md

[changeset-bot]

🦋 Changeset detected

Latest commit: 2dccb5d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 76 packages

Name	Type
@siteimprove/alfa-rules	Minor
@siteimprove/alfa-act	Minor
@siteimprove/alfa-affine	Minor
@siteimprove/alfa-applicative	Minor
@siteimprove/alfa-aria	Minor
@siteimprove/alfa-array	Minor
@siteimprove/alfa-bits	Minor
@siteimprove/alfa-branched	Minor
@siteimprove/alfa-cache	Minor
@siteimprove/alfa-callback	Minor
@siteimprove/alfa-cascade	Minor
@siteimprove/alfa-clone	Minor
@siteimprove/alfa-collection	Minor
@siteimprove/alfa-comparable	Minor
@siteimprove/alfa-continuation	Minor
@siteimprove/alfa-css-feature	Minor
@siteimprove/alfa-css	Minor
@siteimprove/alfa-device	Minor
@siteimprove/alfa-dom	Minor
@siteimprove/alfa-eaa	Minor
@siteimprove/alfa-earl	Minor
@siteimprove/alfa-either	Minor
@siteimprove/alfa-emitter	Minor
@siteimprove/alfa-encoding	Minor
@siteimprove/alfa-equatable	Minor
@siteimprove/alfa-flags	Minor
@siteimprove/alfa-fnv	Minor
@siteimprove/alfa-foldable	Minor
@siteimprove/alfa-functor	Minor
@siteimprove/alfa-generator	Minor
@siteimprove/alfa-graph	Minor
@siteimprove/alfa-hash	Minor
@siteimprove/alfa-http	Minor
@siteimprove/alfa-iana	Minor
@siteimprove/alfa-iterable	Minor
@siteimprove/alfa-json-ld	Minor
@siteimprove/alfa-json	Minor
@siteimprove/alfa-lazy	Minor
@siteimprove/alfa-list	Minor
@siteimprove/alfa-map	Minor
@siteimprove/alfa-mapper	Minor
@siteimprove/alfa-math	Minor
@siteimprove/alfa-monad	Minor
@siteimprove/alfa-network	Minor
@siteimprove/alfa-option	Minor
@siteimprove/alfa-painting-order	Minor
@siteimprove/alfa-parser	Minor
@siteimprove/alfa-performance	Minor
@siteimprove/alfa-predicate	Minor
@siteimprove/alfa-record	Minor
@siteimprove/alfa-rectangle	Minor
@siteimprove/alfa-reducer	Minor
@siteimprove/alfa-refinement	Minor
@siteimprove/alfa-result	Minor
@siteimprove/alfa-rng	Minor
@siteimprove/alfa-sarif	Minor
@siteimprove/alfa-selective	Minor
@siteimprove/alfa-selector	Minor
@siteimprove/alfa-sequence	Minor
@siteimprove/alfa-set	Minor
@siteimprove/alfa-slice	Minor
@siteimprove/alfa-string	Minor
@siteimprove/alfa-style	Minor
@siteimprove/alfa-table	Minor
@siteimprove/alfa-test	Minor
@siteimprove/alfa-thunk	Minor
@siteimprove/alfa-time	Minor
@siteimprove/alfa-toolchain	Minor
@siteimprove/alfa-trampoline	Minor
@siteimprove/alfa-tree	Minor
@siteimprove/alfa-trilean	Minor
@siteimprove/alfa-tuple	Minor
@siteimprove/alfa-url	Minor
@siteimprove/alfa-wcag	Minor
@siteimprove/alfa-web	Minor
@siteimprove/alfa-xpath	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Jym77]

Looks great.

There is a discussion around how we will concretely answer the questions (connection with an AI, …) and how we can reduce the number of requests/tokens used. This may be ignored for now, knowing we can change the rule later on. Two points to consider:

• In the current implementation, the questions are asked sequentially. This means that Dory does not know what is the next question until we get the answer to the current one, and thus each question has to be asked separately. We may still have some special code in Nemo (who is dispatching the questions to further systems) to detect that "does-image-contain-text" should actually ask about all the exceptions in one go and then unpack the answer and store it as several answers. This, however, forces a bit of the logic to be duplicated inside Nemo. Another possibility could be to ask all questions together (which may need a new return type of several boolean, or encoding them in an integer, …); so that if we later decide to add or remove one of them, we do not need any change in Nemo. (or we build a system in the Question class to group several questions into a single one, similar to the classic Promise.all wrapper, this may be the most future-proof solution, but also the most complex one).
• The "logo" exception is a case for which we can certainly make a good heuristic (if the image's name is logo or *_logo_*, or a few other cases) (this would fit the (yet unbuilt) "tier 1" way to answer questions, which I am convinced we'll need to build just to save AI tokens by not asking repeatedly whether logo.jpg has essential text presentation… In the current "sequential" setup, that question is asked second. We could build the heuristic to answer the "does-image-contain-text" question instead, but that is definitely a mismatch (or the heuristic also say "yes" to that question if it detects a logo, which is also a bit confusing). No very neat way here, maybe the "group all questions" approach is the good one.

Anyway, these are probably more things to keep in mind for later and to revisit when we add the rule to the platform.