What a screen reader gets from your HTML and ARIA

What the person hears passes through four layers:

1. The DOM: the elements and attributes your HTML and script produce.
2. The accessibility tree: "User agents acquire information from the DOM and create a parallel structure called the accessibility tree, made up of accessible objects" (AccName 1.1 §1).
3. The platform accessibility API: the browser exposes each object through the operating system's accessibility API, and fires an event when one changes.
4. The assistive technology: a screen reader, voice control or a magnifier asks the API what is there and what changed, and turns it into speech, braille or a command.

Core Accessibility API Mappings (Core-AAM) 1.2 §1.1 lists the APIs browsers map to:

Platform	Accessibility API
Windows	MSAA with IAccessible2, and UI Automation
macOS	macOS Accessibility Protocol (AX API)
Linux	ATK and AT-SPI
Android	Android accessibility API

iOS is not in that list. Each object in the tree carries the same kinds of information, whichever API it reaches:

What	Example	Where it comes from
Role	button, checkbox, link	The element, or a role attribute
Name	"Delete draft"	Content, a label, alt, aria-label or aria-labelledby
Description	"Shown on your profile"	aria-describedby, or title when it isn't the name
States and properties, the value among them	checked, expanded, disabled; a slider's value	The element's own state, or aria-* attributes
Relationships	labelled by, controls, owns; parent and child	label for, aria-labelledby, aria-controls, aria-owns, nesting

Some content never reaches the tree. WAI-ARIA 1.2 counts an element as hidden when it, or an ancestor, is not rendered (display: none) or has aria-hidden="true", and AccName 1.2 lists visibility: hidden as hidden too. Text at opacity: 0, or moved off screen, is not hidden: browsers still expose it. So a badge inside an aria-hidden link leaves the tree with the link, as visible text that screen readers skip shows, while links moved off screen and hidden with aria-hidden still take focus, as aria-hidden content that keyboard focus still reaches shows.

Every HTML element has an implicit role, the one it maps to with no role attribute. HTML Accessibility API Mappings (HTML-AAM) §3.5 sets them out:

Element	Implicit role
<button>	button
<a href="…">	link
<a> with no href	generic
<input type="checkbox">	checkbox, with its checked state
<nav>	navigation
<section>	region when it has an accessible name, generic otherwise
<div>, <span>	generic

A role attribute replaces the implicit role: ARIA lets an element "be understood as a particular widget or structural type regardless of any semantics inherited from the implementing host language" (WAI-ARIA 1.2 §1.1). WAI-ARIA 1.2 §5.3 sorts its roles into six categories:

Category	Roles, for example	What it means for authors
Abstract	command, composite, input, landmark, range, roletype, section, sectionhead, select, structure, widget, window	"Authors MUST NOT use abstract roles in content." They exist to build the model
Widget	button, checkbox, option, slider, switch, tab, textbox; and the composites combobox, grid, listbox, menu, radiogroup, tablist, tree	Interactive: the page provides the keys and the behaviour
Document structure	article, generic, heading, img, list, none, table, toolbar, tooltip	Organises content; not usually interactive
Landmark	banner, complementary, contentinfo, form, main, navigation, region, search	Regions people move between
Live region	alert, log, marquee, status, timer	Content whose changes are announced
Window	alertdialog, dialog	A window inside the page

The aria-* attributes are states and properties. WAI-ARIA 1.2 §6.1 says properties such as aria-labelledby are "often less likely to change" than states such as aria-checked, which "may change frequently due to user interaction", and adds that this "is not a rule; a few properties, such as aria-valuetext are expected to change often". The specification mostly calls both "attributes".

None of this changes what the element does. "Aside from using WAI-ARIA markup to improve what is exposed to accessibility APIs, user agents behave as they would natively" (WAI-ARIA 1.2 §1.3). Take this:

<div role="button">Save changes</div>

The tree now holds a button named "Save changes". The div still takes no focus, and Enter and Space still do nothing, because focus and keys come from the element, tabindex and your script, never from ARIA. Div buttons that can't be reached with Tab shows the rest of that story.

The W3C document Using ARIA set out rules for using ARIA in HTML. Its last Working Draft, of 27 September 2018, had five. On 24 February 2026 W3C published it as a Discontinued Draft, which keeps four rules "for historical purposes and for easier reference" and points to the ARIA Authoring Practices Guide for further guidance. It is informative only: advice, not a requirement.

Rule	What it says	Where it shows
1	Use a native HTML element or attribute with the semantics and behaviour you need, instead of adding ARIA to another element	Div buttons that can't be reached with Tab
2	Don't change native semantics unless you really have to: <div role="tab"><h2>…</h2></div>, not <h2 role="tab">	Using ARIA's own example; WAI-ARIA 1.2 gives a tab presentational children (§5.2.9), so browsers should not expose the h2 as a heading
3	All interactive ARIA controls must be usable with the keyboard	Arrow keys inside a widget: roving tabindex or aria-activedescendant
4	Don't use role="presentation" or aria-hidden="true" on a focusable element	aria-hidden content that keyboard focus still reaches
5 (2018 draft only)	All interactive elements must have an accessible name	Icon-only buttons with no accessible name

The fifth rule is not in the discontinued version, but the need it described has not gone: WCAG 2.2 success criterion 4.1.2 requires a name for every user interface component.

The browser works out the accessible name with the Accessible Name and Description Computation (AccName). Version 1.1, of 18 December 2018, is the W3C Recommendation; version 1.2 is a Working Draft, dated 21 October 2026 at this page's date. Both take the first source that gives a name, in this order (AccName 1.1 §4.3; the step for a control embedded in a label is left out here):

1. Hidden: a hidden element gives no name, unless aria-labelledby, aria-describedby or a label points at it.
2. aria-labelledby: the text of each element it points to, in order. An id that isn't on the page is skipped, as invalid ARIA that misleads screen readers shows.
3. aria-label: its value. It replaces the text inside the element as the name, which is how a button can show "Add to bag" and be named something else, as in buttons and links named differently from their text.
4. The element's own label: a label element, alt, a table's caption.
5. Content: for roles that take their name from content, among them button, link, checkbox, option and tab, the text inside, child by child, with CSS ::before and ::after text. A button holding only an SVG with no title has none, as in icon-only buttons with no accessible name.
6. Tooltip: title, only when nothing above gave a name.

HTML-AAM §4.1 gives each element its own order within those steps. For a text field: aria-labelledby or aria-label, then its label, then title, then placeholder. For a button: aria-labelledby or aria-label, then a label, then its content, then title. For an img: aria-labelledby or aria-label, then alt, then title.

Some roles can't be named at all. WAI-ARIA 1.2 §5.2.8.6 lists them, generic and paragraph among them, and AccName 1.2 says authors "MUST NOT use the aria-label or aria-labelledby attributes" on them. That is why an aria-label on a plain span may never reach the screen reader, as aria-label on divs and spans that screen readers often skip shows.

The accessible description is a separate property. AccName 1.1 §4.2 builds it from the elements aria-describedby points to. AccName 1.2 and HTML-AAM §4.2, both drafts, add a fuller order: aria-describedby, then aria-description, then features such as a table's caption when it isn't already the name, then title when it isn't already the name. aria-description is not in WAI-ARIA 1.2. When each screen reader reads a description is a question of support, not of the tree: see screen reader support. Names and descriptions compared sets the naming attributes side by side.

Both browsers below show the accessibility tree they build from the page. Firefox's inspector shows its own tree, the same on every platform, not the platform API's view of it.

• Chrome: in the Elements panel, select an element and open the Accessibility tab (it may be behind the More Tabs button). It shows the element's place in the accessibility tree, its ARIA Attributes and its Computed Properties. Turn on "Show accessibility tree" to replace the DOM tree with the full-page accessibility tree.
• Firefox: open the Accessibility tab in the developer tools, or right-click the page and choose Inspect Accessibility Properties. The left panel lists each object's role and name; the right panel shows its name, role, actions, value, description, states and relations, among others. Check for issues filters the tree to Contrast, Keyboard or Text Labels problems, and Show Tabbing Order numbers the focusable items.

Browsers word roles their own way: Firefox lists a button as "pushbutton". For each control, read the role, the name, the description and the states, and check each against what the screen shows. The tree says whether the information is there. It doesn't say what a screen reader does with it, which depends on the screen reader, its mode and its version; free accessibility tools lists more ways to look.