aria-accessible-name

[WilcoFiers]

Looks like [role="img"] isn't included in image rules but with the existent has-alt rule just ensure that the element is an IMG element.

We could do this either in a separate rule for role=img, or we can create a list of roles that in aria 1.1 are have "Accessible Name Required: True"

[WilcoFiers]

We'll have to look to exclude elements already tested by other rules.

[Wildebrew]

In recent testing we discovered that Axe does not flag missing accessible name for a modal dialog.
According to the ARIA 1.1 spec entry for the dialog role an element with role="dialog" requires an accessible name (reference the accessible name reqruied entry in the characteristics table at the end of the role description entry).

My interpretation is that if an element requires an accessible name, not providing that name is a WCAG 4.1.2 fail, doesn't matter if the element is an ARIA dialog or an HTML link.

As much fun as WCAG interpretation gymnastics can be, the reason I am commenting is that we found that when a dialog is missing an accessible name,the screen reader experience degrades significantly.

I vote that this issue be addressed, not just for dialog but for any ARIA role where accessible name is required, or at least that the issue be discussed and a formal decision made.

[dylanb]

This should be a best practice

[Wildebrew]

If the ARIA spec is something we believe in, and if that spec requires something, like an accessible name for an element, it should be a violation not to provide it, just like it is a violation not to have a form field without an associated label (or accessible name). To me, I don't see how this is anything except a violation (if we believe it is not necessary, we should file an issue with the ARIA GitHub and recommend this requirement be removed). I do not claim to be infallible, mind, so I defer to whatever decision you think is best here.

…

On 6/15/19, Dylan Barrell ***@***.***> wrote: This should be a best practice -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #470 (comment)

-- Work hard. Have fun. Make history.

[dylanb]

@Wildebrew Thinking through the scenarios here:

1. If the modal has a heading inside it, then the heading should be the accessible name but the fact that it has a heading that can be found means that it is not really creating an accessibility problem. Usability might be improved (also might be decreased) by adding it as a name through (for example) aria-labelledby (best practice would cover this)
2. If the modal does not have a visible "name", then there is no missing information per se, so I don't know which WCAG S.C. this should fail
3. If the modal's content is all in the form of non-text, then the non-text needs to have a text alternative - which will be caught by different checks

Are there other scenarios?

[Wildebrew]

My thought is a bit more fundamental than that. ARIA is fundamentally an accessibility standard, so I feel that anything that violates the requirements of that standard should be called out as a violation. This is a bit different from HTML, because HTML encompasses much more than accessibility and invalid HTML sometimes has limited effect on accessibility, so it is more of a judgment call what is an accessibility violation, best practice or no effect (see duplicate IDs for instance, it is totally situational how severe the impact is). As for the user impact, screen readers still do a bit poorly with dialogs. * aria-modal is not consistently respected * NVDA has a bug where if you place focus on a non-focusable element within a dialog (like a heading with tabindex="-1") it doesn't read anything. And dialogs are not always announced unless they have an accessible name. Those are primarily screen reader issues, but the screen reader experience is consistently better when the dialog has an accessible name. Again, my biggest problem is that Axe doesn't call this at all, so calling it as a best practice is definitely much better than not calling it. But since ARIA specifically requires that dialogs have an accessible name, I think not having one is a violation of ARIA. Since ARIA is exclusively used for accessibility, misuse of ARIA is very likely going to cause an accessibility issue.

…

On 6/15/19, Dylan Barrell ***@***.***> wrote: @Wildebrew Thinking through the scenarios here: 1. If the modal has a heading inside it, then the heading should be the accessible name but the fact that it has a heading that can be found means that it is not really creating an accessibility problem. Usability might be improved (also might be decreased) by adding it as a name through (for example) `aria-labelledby` (best practice would cover this) 2. If the modal does not have a visible "name", then there is no missing information per se, so I don't know which WCAG S.C. this should fail 3. If the modal's content is all in the form of non-text, then the non-text needs to have a text alternative - which will be caught by different checks Are there other scenarios? -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #470 (comment)

-- Work hard. Have fun. Make history.

[honoka-h]

My colleague and I have seen widgets (or parts of them) that do not have accessible names in the past (e.g. tabpanel in a tab). It would be very helpful if axe can report when widgets are missing required accessible names.

[WilcoFiers]

Need to figure out which groups of elements we can test in a single rule. We'll probably need to have multiple rules for this. Part of this was already picked up in existing rules as well.

[WilcoFiers]

We should probably look at ARIA 1.2 rather than 1.1, as some of the things that required an accessible name before don't do so anymore for 1.2:

https://www.w3.org/TR/wai-aria-1.2/

[WilcoFiers]

Primary conversation for this is happening on #2421. I'm closing this as a duplicate.