Give custom widgets a real ARIA role
A widget built from divs and spans has no identity. The role attribute gives it one, using a real value from the ARIA vocabulary, so software can announce tab, or slider, or menuitem instead of nothing. W3C lists ARIA4 as sufficient for 4.1.2 Name, Role, Value in combination with the general technique for exposing name and role through the platform's accessibility features. That partner technique is where the second half of the work lives. The role is a promise, and the promise has to be kept. A tab role that does not respond to arrow keys is worse than no role at all. The software has told the user what to expect, and the widget will not deliver it.
How we find it in an audit
Interactive elements with no role, and roles that are not real ARIA values, are automated finds. The rest is operating the thing. We take every custom widget by keyboard alone and check that the behavior matches the role it claims. The two examples W3C gives, a toolbar and a tree, are both composite widgets where the keyboard contract is most of the work.
How affected users experience it
Screen reader users decide what to do next from what the software says a thing is. Hearing tab tells them arrow keys move between tabs. Hearing nothing at all, on a strip of divs, tells them there is text here and no reason to think it does anything. The whole widget is invisible as a widget, and the content behind the other tabs may as well not exist.
Passes vs. fails
Passes
<div role="tablist">
<button role="tab" aria-selected="true">Overview</button>
<button role="tab" aria-selected="false">Specs</button>
</div>Fails
<div class="tabs">
<div class="tab active" onclick="show(1)">Overview</div>
<div class="tab" onclick="show(2)">Specs</div>
</div>How this gets tested
The W3C publishes test rules that define what a checker looks for here.
- Image button has non-empty accessible nameA tool can check this
- Link has non-empty accessible nameA tool can check this
- ARIA attribute is defined in WAI-ARIAA tool can check this
- ARIA state or property has valid valueA tool can check this
- Element with role attribute has required states and propertiesA tool can check this
- Form field has non-empty accessible nameA tool can check this
- Role attribute has valid valueA tool can check this
- ARIA state or property is permittedA tool can check this
- Button has non-empty accessible nameA tool can check this
- Element with aria-hidden has no content in sequential focus navigationA tool can check this
- Element with presentational children has no focusable contentA tool can check this
- Menuitem has non-empty accessible nameA tool can check this
- Summary element has non-empty accessible nameA tool can check this
- Iframe element has non-empty accessible nameA tool can check this
- Iframe elements with identical accessible names have equivalent purposeA tool finds candidates, you decide
Other ways to satisfy this rule
23 guides on this site are filed under 4.1.2 Name, Role, Value. W3C lists this one as sufficient for that rule only alongside G10, so the pair is what passes and neither half does on its own.
- ARIA5sufficientExpose widget state with ARIA attributes
- ARIA14sufficientLabel icon-only controls with aria-label
- ARIA16sufficientName controls from visible text with aria-labelledby
- G10sufficientBuild custom components on accessibility-supported tech
- G108sufficientExpose name, role, and changes through markup
- G135sufficientExpose controls through the platform accessibility API
This guide is our interpretation of W3C technique ARIA4: Using a WAI-ARIA role to expose the role of a user interface component. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.