Keyboard and screen reader: name, role, state: Through Time

The accessibility tree is what a browser builds from markup for assistive software: every element has a name, a role and a state. Native elements supply them.

A page that is listened to

A person who can’t see the screen doesn’t “listen to a picture.” They listen to the accessibility tree: a parallel tree the browser builds from your markup especially for assistive software. In it every element has three things:

a name: what it is called. A button is “Menu,” a field is “Phone,” an image has its alternative text;
a role: what it is. A link, a button, a heading, a field, a list, navigation;
a state: the condition it is in. Expanded, pressed, selected, current page, an error.

A screen reader (software that reads the screen aloud) puts them together into a phrase like “Menu, button, collapsed.” A large part of making an interface accessible is making sure that phrase is true.

Where does the browser get the name, role and state? The role and behavior come from the element itself: button is a button, a with an href is a link, h2 is a second-level heading. The name is assembled in order from several places: aria-labelledby, aria-label, then the content or a linked label (label for a field, alt for an image), and last of all title. The state comes from attributes (checked, disabled, aria-expanded, aria-current).

The conclusion you already know from the first lesson on ARIA: a native element gives all three at once, and a div gives none. So most often it is enough to choose the right element and give it a name.

How a page is listened to

A screen reader is used differently from the way eyes read. In the WebAIM survey (the eleventh, July and August 2026, with about 1,800 valid responses), most people said that on a long page they begin by going through the headings: roughly two in three. So in browse mode, quick-navigation keys jump between elements of one kind: H to the next heading, D to the next region, F to the next form field, K to a link, B to a button. A screen reader can also show a list of all the headings, all the regions and all the links.

From this follows what you do by hand:

Headings go in order, there is one h1, and you can understand the page from them as from a table of contents.
Regions (landmarks) are marked by the semantic elements you know: header, nav, main, aside, footer. If there are two navigations, each has its own name in aria-label: “Site sections,” “Footer.”
Links make sense out of context. “Read more” in a list of ten links sounds the same ten times. Write “Read more about the service: boundary surveys.”
Fields are labeled. Without a label a screen reader says “edit text” and the person doesn’t know what to type.

Screen readers also differ. By the same survey, on computers people most often use JAWS (paid) and NVDA (free), and on phones VoiceOver on the iPhone and TalkBack on Android. The words differ a little between programs, and the sense is the same.

Check yourself: what does a screen reader build “Menu, button, collapsed” from?

The name “Menu” comes from the button’s content, the role “button” from the button element itself, and the state “collapsed” from the attribute aria-expanded=false.

Keyboard: order, focus and control

You know focus and order from the first pass. Here is what to add for complex elements.

Tab moves between elements, Shift+Tab back. Inside composite elements (a set of radio buttons, tabs, a menu) the arrow keys move between the items, and Tab passes the whole group in one go. For homemade widgets this has to be programmed. The ARIA Authoring Practices Guide describes the expected behavior of each.
Enter activates a link and a button, Space activates a button and checks a checkbox, Esc closes a dialog, a pop-up menu or a tooltip.
Expanding blocks are easiest to make with a button carrying aria-expanded and aria-controls: a screen reader announces “collapsed” or “expanded.” This pattern is called disclosure, and it is worth using in place of homemade “menus” with the menu role, which promises more than it delivers.
Dialogs. A modal dialog must move focus inside, keep Tab from leaving, close on Esc and return focus to the button that opened it. The native dialog element with the showModal() method does all this itself. It is enough to give it a name through aria-labelledby.

Check yourself: what does a dialog element do for the keyboard after showModal()?

It moves focus inside, makes the rest of the page unreachable, closes on Esc and returns focus to the button that opened the dialog.

Messages: what changed on the page

A page changes without reloading: an error appeared, an item went into the cart, a submission went through. A sighted person notices, and a screen reader doesn’t know where to look. The solution is live regions. A container with role="status" (politely: read it when the screen reader is free) or role="alert" (urgently, interrupting the reading) sits in the page in advance, and text is inserted into it later. The screen reader reads the inserted text on its own, and focus doesn’t move.

Two rules. The container must exist before the text is inserted, or many programs won’t announce it. And don’t announce everything: ten messages in a second make a page unbearable.

Hidden: who sees what

display: none and the hidden attribute remove an element for the eyes, the screen reader and the keyboard alike. This is how you hide what is truly not needed (a closed menu).
aria-hidden="true" removes an element only for the screen reader. Focus can still reach it. It is used to hide what is decorative (an icon beside text) and is never put on anything that can take focus.
A “screen reader only” class (the text is shifted off the screen but stays in the tree) is for naming an icon that has no words. Often an aria-label attribute is simpler.

The diagram below has three elements, each written in several ways. See whether Tab reaches it, whether Enter works and what the screen reader says.

What the screen reader says and what Tab does

Choose an element and the way it is written. On the right you see what the keyboard and a screen reader do with it. The screen reader’s words are indicative: each program says it a little differently, and the sense is the same.

<div onclick="open()">Menu</div>

Tab reaches it: ✕ no
Enter and Space work: ✕ no
The screen reader says: “Menu” (plain text, no role named)
Conclusion: Works with a mouse, but not with a keyboard or a screen reader: focus never gets here.

Text alternative: the diagram shows, for a menu button, a field and a dialog, how different ways of writing the markup behave with a keyboard and a screen reader. Native elements (button, a label with an input, dialog) take focus, answer to keys and name themselves; a div with a click handler and a role needs all of that added by hand.

A five-minute check

Turn on a screen reader: NVDA for Windows is free, and VoiceOver in macOS starts with Command+F5. Then:

Close your eyes or look away from the monitor (or turn the screen off).
Go through the headings with the H key. Does a table of contents build up?
Go through the regions with the D key. Is there navigation and main content?
Reach the form with the F key. Did you hear the label of every field?
Do the main action from the brief (a booking, an order). Did you get there? Did you hear the result?

If one of the points failed, that is a priority to fix. For a first time you don’t need to know all the commands: these five keys are enough.

Practice

You stay in the era of 2014. On this page a menu and a dialog are made of div elements and work only with a mouse. Rewrite them with native elements and write in the note what a screen reader will say. The script at the bottom is already attached: it finds elements by id and toggles aria-expanded.

The check looks at markup: at regions, names, states and the absence of homemade buttons. It can’t hear the result. After the lesson, turn on a screen reader and go through the page with your own five-minute routine.

What used to be different

In the jQuery era menus were made of div and span with click handlers, and dialogs of semi-transparent layers, and all of it looked good in a screenshot. For a screen reader such pages were a set of nameless blocks, and a keyboard couldn’t get through them. ARIA appeared to describe what HTML lacked. Now most of what it was invented for exists in HTML itself: button, dialog, details, search. The rule is unchanged: a native element first, and ARIA only after.

Keyboard and screen reader: name, role, state