Screen readers and the first rule of ARIA

The first rule of ARIA is to avoid it: if a native HTML element already does the job, such as button, use that instead of adding a role to a div.

What a screen reader works from

A screen reader does not read pixels. The browser builds an accessibility tree from the HTML, a simplified copy of the page in which every element of interest has a role (button, link, heading, checkbox), a name (the text that identifies it) and sometimes a state (checked, expanded, disabled). The screen reader reads that tree aloud or sends it to a braille display. WCAG 2.2 success criterion 4.1.2 Name, Role, Value, at level A, asks that every control on the page exposes these three things.

Users rarely listen to a page from top to bottom. Screen readers built into the major operating systems, and free ones you can install, let people pull up a list of headings, links or landmarks, jump to the next form field, or read one line at a time. That is why the earlier units matter so much: real headings, labelled fields, buttons that are buttons and alt text all feed directly into that tree. The lang attribute on the html element matters too. Criterion 3.1.1 Language of Page asks for it, and screen readers use it to choose the right voice and pronunciation.

What ARIA adds

WAI-ARIA (Accessible Rich Internet Applications) is a set of attributes that change what goes into the accessibility tree: role sets the role, attributes such as aria-label set the name, and ones such as aria-checked or aria-expanded set the state. ARIA changes only what is announced. It does not make an element focusable, does not add keyboard behaviour and does not change how it looks. The W3C ARIA Authoring Practices Guide puts it in a heading: "No ARIA is better than bad ARIA". Wrong ARIA tells a screen reader user something false about the page.

The rules of ARIA use

The W3C document Using ARIA sets out short rules that are quoted everywhere (it was marked as a discontinued draft in February 2026, but the rules themselves have not changed). Rule 1: if you can use a native HTML element or attribute with the meaning and behaviour you need already built in, do so, instead of repurposing another element with ARIA. Rule 2: do not change native semantics unless you really have to. Rule 3: every interactive ARIA control must be usable with the keyboard. Rule 4: do not put role="presentation" or aria-hidden="true" on an element that can receive focus, or some users will land on "nothing".

Where ARIA does help is in filling gaps HTML cannot. A button that contains only an icon has no text, so it has no name; aria-label="Close" gives it one. An SVG icon next to visible text is decoration, and aria-hidden="true" on the svg keeps it out of the tree. Those are the two attributes most beginners need. For whole widgets such as tabs or menus, follow the matching pattern in the Authoring Practices Guide rather than inventing one.