How Semantic HTML Shapes the Accessibility Tree

Semantic HTML gives browsers information about the purpose and relationships of elements on a webpage. The browser can use that information, together with ARIA attributes, element states, text, labels, and rendered styles, to construct an accessibility tree for assistive technologies.

This relationship is important, but it is not a simple copy. The accessibility tree is a specialized representation of the interface. It exposes relevant roles, names, states, properties, and relationships while leaving out many implementation details that are not useful to assistive technology.

What is an accessibility tree?

An accessibility tree is a browser-generated representation of the parts of a webpage that are relevant to accessibility. Assistive technologies can use this representation to understand and operate the interface.

Depending on the browser, operating system, and assistive technology, the accessibility tree may communicate information such as:

an element’s role, such as heading, button, link, navigation region, or checkbox;
its accessible name, such as the text that identifies a button or form field;
its current state, such as checked, expanded, selected, disabled, or pressed;
its value, when the element has one;
relationships between labels, controls, descriptions, headings, and regions;
whether the element is available for interaction; and
how the element fits into the surrounding accessibility structure.

The browser makes this information available through platform accessibility APIs. Screen readers, voice-control software, switch-access systems, and other assistive technologies may then use those APIs in different ways.

For a broader explanation of this browser representation, see Accessibility Tree Explained.

How semantic HTML contributes to the accessibility tree

Semantic HTML contributes built-in meaning. An element such as <button>, <nav>, <h2>, or <input type="checkbox"> identifies more than visual appearance. It describes the element’s purpose in the document or interface.

The browser can translate much of that meaning into accessibility information. For example:

Examples of HTML semantics and their likely accessibility meaning
HTML structure	Meaning supplied by HTML	Likely accessibility exposure
`<h2>`	A second-level heading	A heading with level 2
`<button>`	An interactive button	A button with keyboard behavior and an accessible name
`<a href="...">`	A link to another resource or location	A link that can be focused and activated
`<nav>`	A major group of navigation links	A navigation landmark
`<main>`	The page’s primary content	A main landmark
`<input type="checkbox">`	A checkbox control	A checkbox with checked or unchecked state
`<ul>` and `<li>`	An unordered list and its items	A list structure with a number of list items

The exact result can vary across browsers, operating systems, accessibility APIs, and assistive technologies. The essential principle remains stable: meaningful HTML gives the browser stronger source material from which to create a useful accessibility representation.

The DOM and accessibility tree are related, but not identical

After parsing an HTML document, the browser creates the Document Object Model, commonly called the DOM. The DOM represents the document as nodes that scripts and browser systems can inspect or modify.

The accessibility tree draws from the DOM, but it is not a complete duplicate of it. The browser also considers factors such as:

native HTML semantics;
ARIA roles, states, and properties;
associated labels and descriptions;
current control values and interaction states;
whether content is rendered or hidden;
some CSS effects;
browser accessibility mappings; and
changes made by JavaScript.

Some DOM nodes do not need separate accessibility objects. A generic wrapper used only for layout may not carry meaningful accessibility information. Other nodes may be omitted because they are hidden, decorative, or absorbed into the accessible representation of a parent element.

This is why visual presence, DOM presence, and accessibility-tree presence should not be treated as interchangeable:

An element can exist in the DOM but be absent from the rendered page.
An element can exist in the DOM but be excluded from the accessibility tree.
Visible text can become the accessible name of a parent control rather than appear as a separately navigable object.
An element can look like a button without being exposed or behaving like one.

The accessibility tree is therefore a purpose-built interpretation of the interface, not simply another view of the source code.

Roles, names, states, and relationships

Semantic structure becomes especially useful when it communicates several kinds of information together.

Role

A role describes what an element is or what it does. Native HTML frequently provides this role automatically. A <button> is exposed as a button, while a properly formed heading is exposed as a heading.

Accessible name

An accessible name identifies an element. It may come from visible text, a properly associated <label>, alternative text, aria-label, or aria-labelledby, depending on the element and context.

For example:

<button type="button">Save draft</button>

The native element supplies the button role, while the visible text supplies the accessible name “Save draft.”

State and value

Interactive controls often have changing states or values. A checkbox can be checked or unchecked. A disclosure button can be expanded or collapsed. A slider has a current value within a range.

Native controls usually communicate their standard states automatically. Custom controls may require carefully managed ARIA attributes and JavaScript behavior.

Relationships

Meaning also depends on relationships. A form label identifies its control. A description provides additional instructions. A table header gives context to related cells. A heading introduces the section that follows it.

These relationships help an assistive technology provide more than isolated fragments. They help communicate how the page is organized and how its parts belong together.

Native HTML usually provides the strongest starting point

Native HTML elements generally combine several accessibility features that would otherwise need to be recreated. A real button provides semantics, keyboard focus, keyboard activation behavior, and state handling expected by browsers and assistive technologies.

Compare these two examples:

<div class="button" onclick="saveDraft()">Save draft</div>

<button type="button" onclick="saveDraft()">Save draft</button>

The first element may look like a button after CSS is applied, but a generic <div> does not become a button because of its appearance or click handler. It does not automatically receive button semantics, keyboard focus, or expected keyboard activation.

The second example begins with the correct control. The browser already understands its role and behavior.

ARIA can supplement native HTML when additional semantics are necessary, especially in complex custom widgets. It should not be used to replace appropriate native elements without a sound reason. Adding role="button" to a <div>, for example, changes its exposed role but does not automatically reproduce all native button behavior.

This distinction is explored further in When ARIA Is Unnecessary: Let Native HTML Do the Work and ARIA and Accessible Applications.

Page structure creates navigable accessibility patterns

Semantic structure does more than identify individual controls. It can give the page an understandable overall shape.

Headings establish an outline

Headings identify sections and levels within the content. Many screen-reader users navigate from heading to heading or open a list of headings to understand the page before reading it in detail.

A heading should therefore describe the section it introduces. Heading levels should reflect content hierarchy rather than the visual size a designer wants. CSS can control appearance without changing structural meaning.

See Heading Hierarchy: How to Structure Web Content Clearly.

Landmarks identify major regions

Elements such as <header>, <nav>, <main>, <aside>, and <footer> can contribute landmark information. Landmarks help users move among major page regions without traversing every intermediate element.

Landmarks are most useful when they reflect genuine regions rather than wrapping every small group of content in a semantic element. When a page contains more than one navigation region or similarly typed landmark, accessible names can help distinguish them.

<nav aria-label="Primary">
  ...
</nav>

<nav aria-label="Article topics">
  ...
</nav>

See HTML Landmarks Explained for a closer look at meaningful page regions.

Lists, tables, and forms preserve relationships

A list identifies a related set of items. A properly structured data table associates headers with rows and columns. A form connects controls with labels, instructions, groups, validation states, and error messages.

When visual layout is used without corresponding semantics, these relationships may be apparent to a sighted reader but unclear in the accessibility tree.

What may be excluded from the accessibility tree?

Not every element belongs in the accessibility tree. Excluding content can be correct when that content is hidden, redundant, decorative, or irrelevant to interaction. Problems arise when meaningful or operable content is removed unintentionally.

Content hidden from everyone

The HTML hidden attribute and CSS such as display: none generally remove content from visual rendering and the accessibility tree. This is usually appropriate when the content is not currently available to any user.

Content hidden only from assistive technology

aria-hidden="true" can remove an element and its descendants from the accessibility tree while leaving them visually displayed. This may be appropriate for decorative or duplicated content, but it requires care.

Interactive, focusable elements should not remain inside an aria-hidden="true" region. Otherwise, a keyboard user may be able to move focus to a control that is missing from the accessibility representation.

Decorative images

An image with an empty alternative text attribute, alt="", is generally treated as decorative and omitted from the meaningful accessibility experience. That can prevent repeated or irrelevant visual details from interrupting the content.

An image that communicates information needs a suitable text alternative instead. The decision depends on the image’s purpose in context, not only on what it depicts. See Accessible Images and Alternative Text.

Generic layout containers

Many <div> and <span> elements exist only to support styling or scripting. They may not need their own meaningful accessibility object. Their text and meaningful descendants can still contribute to the surrounding accessible content.

Dynamic interfaces can change the accessibility tree

The accessibility tree is not necessarily fixed after the page first loads. JavaScript can add, remove, rename, disable, expand, collapse, or otherwise modify interface elements. Browsers can reflect these changes through accessibility APIs.

For a dynamic component to remain understandable, its semantic state should change with its visual state. Consider a button that opens and closes a navigation panel:

<button
  type="button"
  aria-expanded="false"
  aria-controls="site-menu">
  Menu
</button>

<nav id="site-menu" aria-label="Site menu" hidden>
  ...
</nav>

When the menu opens, the script should remove the hidden attribute and update aria-expanded to true. When it closes, both conditions should be reversed.

This keeps several layers aligned:

what is visible;
what is operable;
what exists in the accessibility tree;
what state the controlling button communicates; and
what keyboard focus can reach.

Changing appearance without updating semantics can create contradictory interfaces. A panel may look open while the accessibility state still says collapsed, or a hidden dialog may continue receiving keyboard focus.

How to test semantic structure and accessibility exposure

Valid HTML and thoughtful semantics provide a strong foundation, but testing is still necessary. Browser mappings and assistive-technology behavior are complex, and custom interaction patterns can introduce problems that are not visible in source code alone.

Inspect the accessibility tree

Modern browser developer tools can show an element’s computed accessibility information. Depending on the browser, this may include its role, accessible name, state, properties, and location in the accessibility tree.

Inspection can help answer practical questions:

Is this element exposed as the intended role?
Does the control have an understandable accessible name?
Is a hidden element still present?
Is a decorative element creating unnecessary noise?
Does the expanded, selected, checked, or disabled state update correctly?
Are landmarks and headings represented as expected?

Test keyboard operation

Accessibility-tree information does not guarantee usable interaction. Test whether all relevant controls can be reached and operated with a keyboard, whether focus remains visible, and whether focus moves logically when content opens or closes.

Keyboard Navigation Best Practices provides additional guidance.

Test with assistive technologies

Screen-reader testing can reveal how semantic information is announced and navigated in practice. Testing more than one browser and assistive-technology combination may be appropriate for important workflows because implementations differ.

Use automated tools as one layer

Automated accessibility tools can find some missing names, invalid ARIA attributes, contrast issues, and structural errors. They cannot determine every contextual question, such as whether a label is genuinely clear or whether focus movement makes sense to a person completing a task.

Useful review combines automated checks, structural inspection, keyboard testing, and human judgment.

Common semantic structure mistakes

Choosing elements for appearance rather than meaning

A heading should identify a heading, a button should perform an action, and a link should navigate to a destination. Visual styling can be changed with CSS; structural meaning should remain tied to purpose.

Making a generic element clickable

A click handler does not supply native keyboard behavior or complete accessibility semantics. Start with the appropriate native interactive element whenever one exists.

Adding redundant or conflicting ARIA

ARIA can override or conflict with native semantics. Unnecessary roles may make code harder to maintain without improving the accessibility tree. Begin with native HTML, then add ARIA only where it communicates information that HTML does not already provide.

Using placeholders as form labels

A placeholder is not a durable replacement for a label. It may disappear after input begins, and it does not provide the same visible and structural relationship as a properly associated <label>.

Hiding content from the tree while leaving it focusable

This can create an interaction that is reachable by keyboard but unavailable to assistive technology. Visual visibility, focusability, operability, and accessibility exposure should be reviewed together.

Assuming visual order communicates structural order

CSS can rearrange content visually without changing its DOM or accessibility reading order. If the resulting sequences differ substantially, keyboard and screen-reader users may encounter the page in an order that no longer matches its visual presentation.

Additional examples appear in Common Semantic HTML Mistakes and How to Correct Them.

A practical model for thinking about semantic accessibility

The relationship between HTML and assistive technology can be understood as a sequence:

The author chooses HTML elements and attributes.
The browser parses the document and creates the DOM.
CSS and scripts influence presentation, state, and visibility.
The browser interprets relevant semantics and constructs an accessibility representation.
The browser exposes that information through a platform accessibility API.
Assistive technology interprets and presents the information to the user.

Each layer matters, but authors have the strongest direct influence at the beginning of the sequence. Clear native structure gives later layers more reliable information to work with.

This does not mean that semantic HTML alone guarantees accessibility. Color contrast, keyboard interaction, focus management, instructions, error handling, language clarity, media alternatives, and many other concerns remain important. Semantic structure is one foundation within the larger practice of accessibility engineering.

Frequently asked questions

Does the accessibility tree contain every DOM element?

No. The accessibility tree is a specialized representation rather than a full copy of the DOM. Hidden, decorative, generic, or otherwise irrelevant nodes may be omitted, combined, or represented through a parent element.

Does semantic HTML automatically make a page accessible?

No. Semantic HTML provides an important foundation, but complete accessibility also depends on keyboard behavior, visual presentation, content clarity, focus management, labels, error handling, media alternatives, and testing.

Can ARIA change the accessibility tree?

Yes. ARIA can modify exposed roles, names, states, properties, and relationships. It generally does not add native behavior, however. A custom element given role="button" still needs appropriate focus and keyboard interaction.

Can something be visible but absent from the accessibility tree?

Yes. For example, aria-hidden="true" can leave content visually displayed while removing it from the accessibility tree. This should be used carefully, especially around interactive or focusable content.

Semantic structure gives accessibility systems useful meaning

Semantic HTML helps browsers understand what page elements are, how they relate to one another, and how people may interact with them. Browsers can carry that meaning into the accessibility tree as roles, names, states, values, landmarks, and structural relationships.

The accessibility tree is not a direct copy of the HTML or DOM. It is a changing, purpose-specific representation shaped by native semantics, ARIA, browser mappings, rendered state, and interface behavior.

Using the right HTML element for the job remains one of the most durable accessibility practices available. It reduces the amount of behavior authors must recreate and gives browsers and assistive technologies clearer information from the beginning.