Use native HTML controls instead of rebuilt ones
A native control arrives with its role, its keyboard behavior and its focus handling already built by the browser. Rebuild the same thing out of a div and you inherit none of that. Every missing piece has to be hand-added, then hand-maintained forever. W3C lists H91 as sufficient for 2.1.1 Keyboard when it is used for keyboard control. It is sufficient for 4.1.2 Name, Role, Value too, paired there with G108, the technique for exposing name and role through markup. The scope is narrower than the idea, though. H91 covers HTML form controls and links, so headings, lists and landmarks get their semantics from other techniques. W3C also states the mechanism in one line worth keeping. The role comes from the element, and the name comes from the text associated with that element, which in practice means a label element, aria-label, aria-labelledby, or the title attribute. One trap hides inside all of this. An a element with no href is not a link at all. A styled anchor wired up in JavaScript has no role, no focus and no keyboard behavior, exactly like the div it was meant to improve on.
How we find it in an audit
We read the accessibility tree behind every control that looks custom on an audited page. A button whose role comes back generic, a dropdown that turns out to be a stack of divs, an anchor with no href. Each one becomes a finding that names the native element replacing it, which is nearly always the answer, or the full ARIA pattern where a native element genuinely cannot do the job. The tree is the evidence, because the screenshot looks fine.
How affected users experience it
A native button announces itself as a button and answers Enter and Space. Add to cart, button. A div made to look like one announces its text as ordinary prose. The listener hears the words add to cart in the middle of a paragraph, with nothing marking them as pressable, and the keyboard never reaches them anyway. They walk past the most important control on the page without knowing it was there. Voice control users hit the same wall from another direction, because there is no control for the command to attach itself to.
Passes vs. fails
Passes
<button type="button" onclick="buy()">Buy now</button>
<a href="/cart">Cart</a>Fails
<div class="btn" onclick="buy()">Buy now</div>
<a onclick="goToCart()">Cart</a>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
- Iframe with interactive elements is not excluded from tab-orderA tool can check this
- Scrollable content can be reached with sequential focus navigationA tool can check this
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 G108, so the pair is what passes and neither half does on its own.
- ARIA4sufficientGive custom widgets a real ARIA role
- 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
This guide is our interpretation of W3C technique H91: Using HTML form controls and links. 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.