axe-core
axe-core copied to clipboard
Should aria-prohibited-attr account for widget parents?
The aria-prohibited-attr check flags use of aria-label on elements where it will be ignored. In building that, we did not account for scenarios like the following, where because of the way the accessible name calculation works, the aria-label attribute is used in the name of the parent widget.
<button>
<span aria-label="hello world"></span>
</button>
We need to do testing on this. Figure out if this works consistently across the supported AT, and if there are any differences between different browsers. For example, do links behave differently than buttons, because links don't have presentational children, but buttons (in some browsers) do. Does it matter if this is a native element, or an element with a role attribute. Does it matter if the element is focusable or not?
I'd like to see someone put together some test cases and try them with JAWS, NVDA & VO.
Tested with the following HTML:
<h2>button</h2>
<button>
<span aria-label="native button"></span>
</button>
<h2>link</h2>
<a href="#">
<span aria-label="native link"></span>
</a>
<h2>role=button</h2>
<div role="button" tabindex="0">
<span aria-label="role button"></span>
</div>
<h2>role=link</h2>
<div role="link" tabindex="0">
<span aria-label="role link"></span>
</div>
- VO / Safari - Only the native button was focusable (using tab), announced as "native button, button." I wasn't able to focus the others nor navigate to them using line-by-line. Rotor menu was able to bring up both buttons in the Form Controls menu, both listed using
aria-labelas the name. Ditto for the Links menu. - JAWS / IE11 - Can navigate to each one with either tab or line-by-line, names are announced using the
aria-label.Removing thetabindexfrom the non-native elements did not change the behavior (other than not being able to tab to them). - JAWS / Chrome - Same as JAWS / IE11
- NVDA / Firefox - Same as JAWS / IE11
So it looks like only VO / Safari has issues with it.
Thanks for the testing. That sort of confirms what I was suspecting. So then there isn't really an issue in doing using aria-label on descendants of widgets. Lets add in an exception that for such cases.
This gets a bit more interesting as the following HTML also reads the name of the aria-label in all 3 screen readers / browsers.
<span id="foo" aria-label="foo"></span>
<!-- reads as "foo button" -->
<button aira-labelledby="foo"></button>
<!-- reads as "foo graphic" -->
<div role="img" aria-labelledby="foo"></div>
<!-- reads as "heading level 2 foo" -->
<div role="heading">
<span aria-label="foo"></span>
</div>