Lesson 10 · Structure and meaning

Accessibility and ARIA

A screen reader never sees your page. It reads the accessibility tree: the browser's summary of what each element is (its role), what it is called (its name) and how it is now (its state). Follow eight lines of HTML into that tree, hear what a screen reader says for each, watch Tab skip the parts that are not controls, and learn what ARIA attributes can and cannot fix.

10 min11 steps5 questionsIntermediate

Fig 10 · Interactive

Loading figure…

or ← →

Check yourself

5 quick questions

Pick an answer to see why. Your score saves with your progress.

01What does a screen reader read?

The browser turns the HTML into an accessibility tree of nodes with a role, a name and a state. Screen readers read that tree, which is why the HTML you choose matters.

02Why is <div class="btn">Save</div> a poor button, even if CSS makes it look like one?

A div means nothing: its node gets the role generic. It is not focusable and has no keyboard behaviour. A <button> gets all of that for free.

03What does alt="" (an empty alt) tell assistive technology?

An empty alt marks the image as decorative, and screen readers skip it. An image that carries meaning needs alt text that says what it shows.

04An icon button shows only ×. Which markup gives it the name "Close"?

aria-label sets the node's name, so the reader says "Close, button". The × still shows on screen: ARIA changes only the tree. alt works only on images, so a button ignores it; role and aria-expanded do not set a name.

05You add role="button" to a div. What do you still have to add yourself?

ARIA only changes the tree. The div still cannot take focus or respond to keys until you add tabindex and JavaScript. That is why the first rule of ARIA says: use <button> when you can.

Key terms

Glossary

Accessibility: Making a page usable by everyone, including people who use a screen reader, only a keyboard, or other assistive technology.
Screen reader: A program that reads a page aloud (or to a braille display), such as NVDA, JAWS or VoiceOver.
Accessibility tree: The browser's summary of the page for assistive technology: one node per meaningful element, each with a role, a name and sometimes a state.
Role: What a node is, such as button, image or search box. Native HTML elements have one built in.
Accessible name: What a node is called: a button's text, an image's alt, a field's label, or an aria-label.
State: How a node is right now, such as expanded or collapsed, checked or not.
ARIA: Accessible Rich Internet Applications: attributes such as role, aria-label and aria-expanded that edit the accessibility tree. They do not change looks or behaviour.
Focus: Which element receives the keyboard. Tab moves focus to the next control in the order of the HTML.

Fine print

Notes and sources

Screen readers word things differently (NVDA, JAWS and VoiceOver each have their own phrasing and order). The figure shows the name, role and state they all receive.
The tree on the right is simplified. A real one also holds the page itself, the label's own text and plain text nodes; the div's word "Save" sits there as plain text, which is why it is still read.
ARIA attributes change only the accessibility tree. They never change how an element looks or what the keyboard does with it.
The card is real HTML. The menu itself is left out: a full page would also have the list the Menu button opens, usually linked with aria-controls.

Quiz Unlocks after the last step.