Compatible with Assistive Technologies

Web content is compatible with assistive technologies when the browser correctly transmits its information (name, role, value, states) to screen readers, braille displays, and other assistive tools. Native HTML elements like <button> or <input> are automatically compatible. Generic elements like <div> are not, unless manual addition of WAI-ARIA attributes and keyboard behaviors.

Your button works with a mouse. It has the right color, the right size, the right cursor. A screen reader user arrives on the page : this button doesn't exist. The screen reader doesn't see it, doesn't announce it, and the user can't activate it. The button is not compatible with assistive technologies.

#What happens between the browser and the screen reader

The browser builds an accessibility tree from the DOM. It's a simplified version of the page where each interactive element is described by four properties : its name (the displayed text or the aria-label attribute), its role (button, link, checkbox…), its value and its state (checked, expanded, disabled…). This tree is transmitted to the accessibility API of the operating system, which makes it readable by assistive technologies.

A native HTML <button> automatically exposes its role and state. No additional attributes are necessary. A <div> with an onclick, on the other hand, exposes nothing : for the accessibility tree, it's inert text.

<!-- Compatible: the browser knows this is a button -->
<button>Submit order</button>
 
<!-- Incompatible: the browser doesn't know this is a button -->
<div onclick="submit()">Submit order</div>

#The trap of role without behavior

Adding role="button" to a <div> isn't enough. The W3C sums it up in one sentence : "A role is a promise." By declaring that an element is a button, you promise that it responds to Enter and Space keys, that it's reachable via keyboard tabulation, and that its states are dynamically updated.

<!-- Promise kept: role + keyboard + focus -->
<div role="button" tabindex="0"
     onkeydown="if(event.key==='Enter'||event.key===' ')submit()"
     onclick="submit()">
  Submit order
</div>
 
<!-- Promise broken: the screen reader says "button",
     but the user can't activate it from the keyboard -->
<div role="button" onclick="submit()">
  Submit order
</div>

Five lines of code to recreate what a <button> does natively in a single line. WCAG criterion 4.1.2 (level A) requires that each user interface component exposes its name, role, and value via the accessibility API. The RGAA restates this requirement in its glossary and in its criteria for topic 7 (Scripts).

#In summary

Use native HTML elements. They're compatible with assistive technologies by default. If you must use an interactive <div> or <span>, add the ARIA role, the tabindex, keyboard handling, and state updates. A role without behavior is worse than no role at all.

Back to glossary
Share this article

Learn more

Assistive Technologies

Assistive technologies are the software and hardware that people with disabilities use to navigate the web: screen readers, magnifiers, voice commands, braille displays, switches. They depend entirely on the quality of the HTML code to function correctly.

Screen reader

A screen reader is software that converts screen content into speech synthesis or braille. It traverses the browser's accessibility tree, not the design, to convey page structure to blind or low-vision users.

ARIA

ARIA (Accessible Rich Internet Applications) is a set of HTML attributes that describe interface components to assistive technologies. A custom button, a tabbed system, a dynamic notification: when semantic HTML is not enough, ARIA adds the missing information. But an ARIA attribute without the corresponding behavior does more harm than good.