Open annethyme opened 1 year ago
Chrome is giving this link (and image) no name, while Firefox give them a name of "W3C" 🙈 So, I guess we're both somewhat right…
Based on the information from the W3C HTML AAM specification (https://www.w3.org/TR/html-aam-1.0/#img-element-accessible-name-computation), I support the Chrome approach as it follows the guidelines for computing the accessible name of an image, and consequently in favour of the Siteimprove approach:
- If the img element has an aria-label or an aria-labelledby attribute the accessible name is to be calculated using the algorithm defined in Accessible Name and Description: Computation and API Mappings. (since the image element does not have aria-label or aria-labelledby attributes, we move to the next step)
- Otherwise use alt attribute, even if its value is the empty string. (therefore, the accessible name of the image is determined by the alt attribute value, which is empty - current scenario)
- Otherwise, if there is no alt attribute use the title attribute. (as there is no need to consider the title attribute when the alt attribute is present, it can be ignored)
- Otherwise there is no accessible name. (since the alt attribute is empty, the image is considered decorative, and no accessible name is assigned to it)
Consequently, the link that contains the decorative image will result in an empty link.
In contrast, as @Jym77 said, when using Firefox with NVDA, the purpose of the link can still be understood.
Talked about this during today's ACT TF call. The four of us think this might be better handled in a new rule that looks at inconsistencies between different attributes that can provide an accessible name. alt + title is one of those, but aria-label + alt also.
A similar issue that was filed as a bug report with Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1700174
I found that Siteimprove (browser extension) and Qualweb handles this case differently:
<a href=“http://w3.org/”><img alt title=“W3C” /></a>
(I hope I distilled the example correctly since I cannot show the real one)Siteimprove reports that the link does not have an accessible name, while the element does not fail in Qualweb. I guess it is because in Siteimprove the empty alt takes precedence, marking the image as decorative, and thus reporting that there is no accessible name for the link, whereas Qualweb sees that the image has a title and interprets that as the accessible name for the image and therefore also for the link.
I am guessing that this discrepancy between implementations is not limited to this one rule, but now I just marked it for the rule where I noticed it.