Browser Accessibility Tree and DevTools

I’ll work through the anti-checklist systematically before editing.

Video: Browser Accessibility Tree and DevTools

Archetype check: Fix-Focused Technical Article. The draft follows the required_modules and section_strategy correctly. No forbidden modules present. No WebAIM 94.8% opener. No lawsuit-volume hook. Structure is sound.

Hook: Strong and specific. Keep it. Minor tightening only.

Generic phrases: Scanning… None of the flagged phrases appear. Clean.

Passive voice: A few instances. Most are acceptable. One or two worth flipping.

Filler sentences: A few present, particularly in transitions.

Bullet overuse: The node properties (Name/Role/Description/State) are a four-item bullet list that could be tightened, but they serve a reference function. The five errors section uses bold headers rather than bullets. Acceptable.

CTA: The mid-article CTA paragraph is clean. The closing paragraph is strong but the very last sentence is slightly listy. The final paragraph mentions the free scanner naturally, no standalone scanner-promo section exists. Good.

Weasel stats: None present.

Em/en dashes: The draft uses em dashes throughout. All must be replaced per house style.

Structural balance: Sections are proportionate to purpose. DevTools section is appropriately the longest.

Ending: Solid. The last paragraph is operational and ends on a concrete action. Keep the shape, tighten the language.

Distinctiveness: Opening and closing are specific enough. Hold.

Same-length paragraph sequence: The “What Controls Which Elements” section has several same-length paragraphs. Vary rhythm there.

Key edits needed: 1. Replace all em dashes with period, comma, colon, or parenthesis. 2. Remove filler transitions. 3. Tighten the node properties list intro. 4. The sentence “These are not edge cases” is good but the following sentence is slightly listy. Tighten. 5. The closing paragraph of “Accessibility Tree Failures” section has a slightly awkward construction. Fix. 6. “The opacity: 0 row is the one that catches teams off guard.” — good, keep. The paragraph after the table repeats what the table callout already signals. Trim. 7. In the five errors section, error 2 says “Assistive technology receives no actionable information about the element’s purpose” — this is slightly generic. Sharpen. 8. The FAQ answer for “Can CSS break the accessibility tree?” gives a slightly muddled instruction about aria-hidden. Clean it up. 9. The closing paragraph is good but “work through the computed name panel for every interactive element” is slightly listy. Keep the operational feel, tighten the sentence.

---

A button passes visual QA. It has a background color, an icon, and a hover state. Then you open Chrome DevTools, click the Accessibility tab, and the computed name field is blank. The accessibility tree has no idea what this button does. That blank field is a WCAG 4.1.2 Name, Role, Value failure. According to ADA.gov’s guidance on web accessibility, courts applying WCAG 2.1 AA as the de facto standard for ADA Title III compliance look for exactly this kind of programmatic failure.

Visual inspection does not catch it. User testing might. DevTools will, every time.

This article shows you what the accessibility tree is, what controls it, how to inspect it in Chrome, Firefox, and Edge, and which errors to prioritize when you find them.

---

What the Accessibility Tree Is (and How It Differs from the DOM)

The accessibility tree is a browser-generated representation of a web page that assistive technologies (including screen readers, voice control software, and braille displays) use to interpret and navigate content. Unlike the DOM, which contains every element on a page, the accessibility tree includes only the elements meaningful to assistive technology. Each node carries four properties:

• Name: the element’s label, announced by a screen reader. Also called the “computed name” or “accessible name” — these terms refer to the same value, calculated by the browser from aria-label, aria-labelledby, visible text content, or a title attribute, in that priority order.
• Role: what kind of element it is (button, heading, link, checkbox).
• Description: additional context, typically from aria-describedby.
• State: dynamic properties such as checked, expanded, disabled, or hidden.

Think of the DOM as the full blueprints of a building and the accessibility tree as the version handed to the fire inspector: only the load-bearing structure, exits, and safety labels. The browser strips layout-only and decorative nodes. What remains is the semantic skeleton.

When that skeleton is broken — a name is empty, a role is wrong, a node is missing — assistive technology either announces garbage or nothing at all.

---

What Controls Which Elements Enter the Tree

Three inputs determine what the accessibility tree contains: native HTML semantics, ARIA attributes, and CSS.

Native HTML elements carry built-in roles. A <button> is automatically assigned role="button" and is focusable by default. An <h2> carries role="heading" with level 2. A <div> carries no meaningful role and does not appear as interactive.

ARIA attributes add or override tree information. aria-label sets the computed name directly. aria-hidden="true" removes an element from the tree entirely while leaving it in the DOM.

CSS is where most developers are surprised:

CSS / Attribute	Effect on Accessibility Tree
display: none	Removes element and all children from the tree
visibility: hidden	Removes element from the tree
aria-hidden="true"	Removes element from tree; DOM is unchanged
opacity: 0	Element stays in the accessibility tree
Native <button>	Auto-assigned role="button", focusable by default

The opacity: 0 row is the one that catches teams off guard. An element with zero opacity is visually invisible but fully present in the accessibility tree. Screen readers will announce it. Keyboard users can focus it. Hiding something visually with opacity: 0 is not the same as hiding it from assistive technology. If that invisible element has no name, it fails WCAG. If it has a name but should not be interactive, it confuses users.

---

Accessibility Tree Failures and the WCAG Criteria They Violate

WCAG Success Criterion 4.1.2 Name, Role, Value requires that every user interface component have a name and role that can be programmatically determined. The accessibility tree is exactly where “programmatically determined” gets tested. If the tree does not carry the name, no assistive technology can retrieve it.

The table below maps specific tree failures to the WCAG success criteria they violate.

Accessibility Tree Failure	WCAG Success Criterion	Severity
Button or link has no computed name	4.1.2 Name, Role, Value	Critical
Link role is missing or incorrect	4.1.2 / 2.4.4 Link Purpose in Context	Critical
Heading hierarchy is skipped	1.3.1 Info and Relationships	Serious
Form field absent from the tree	4.1.2 / 1.3.1 Info and Relationships	Critical
Decorative image not removed from tree	1.1.1 Non-text Content	Moderate

These are the failures that appear in ADA demand letters. According to ADA.gov’s guidance, ADA Title III carries no government-mandated compliance deadline for web accessibility. Enforcement is lawsuit-driven, and courts consistently apply WCAG 2.1 AA. Fixing tree errors is not optional remediation. It is the specific technical act courts look for when determining whether a site met Level AA.

Federal contractors face an additional layer of obligation. Section 508 Compliance: Who It Covers and How to Test explains how WCAG 2.0 AA maps to procurement requirements for government work.

A free website accessibility checker queries the accessibility tree programmatically — the same way a screen reader does — and surfaces empty computed names, missing roles, and excluded form fields without requiring DevTools access.

---

How to Inspect the Accessibility Tree in Chrome, Firefox, and Edge

Each major browser exposes the accessibility tree through its developer tools. The data comes from the same underlying OS accessibility APIs, so results should match across browsers for any given element.

Chrome DevTools

1. Open the page in Chrome.
2. Right-click any element and select Inspect, or press F12.
3. In the Elements panel, find the Accessibility tab in the bottom drawer. If it is not visible, click the » overflow arrow to reveal hidden tabs.
4. Select any element in the DOM tree. The Accessibility pane shows its computed name, role, description, and state.
5. To view the full-page accessibility tree: click the Switch to Accessibility Tree View icon (the person/figure icon in the top-right corner of the Elements panel).

What to look for: any node labeled generic with no name is a red flag. Buttons and links with an empty Name field fail WCAG 4.1.2 immediately.

Firefox Accessibility Inspector

1. Press F12 and click the Accessibility tab.
2. If prompted, click Turn On Accessibility Features.
3. The tree populates automatically. Expand any node to inspect its role, name, and state.
4. Use the Pick Accessible Object button (crosshair icon in the toolbar) to click any visual element on the page and jump directly to its tree node.

Firefox-specific advantage: the Inspector highlights issues inline with color-coded severity indicators, making quick triage faster than Chrome’s panel without writing any code.

Microsoft Edge DevTools

1. Press F12, open the Elements panel, and click the Accessibility tab in the bottom drawer.
2. Open the Issues panel (also in DevTools) for a pre-flagged list of accessibility tree violations (missing names, ARIA conflicts) with direct links to the relevant WCAG criterion documentation.

Edge’s Issues panel is particularly useful for agency reporting: it outputs violations as a numbered list with criterion references already attached.

---

Five Accessibility Tree Errors Worth Finding First

Each entry below states what the tree shows, what the user impact is, and what to fix.

1. Missing computed name on a button or link The tree shows Name: (empty). A screen reader announces “button” with no label. The user has no idea what activating it will do. Fix: add visible text inside the element, or use aria-label="Descriptive label" if the button is icon-only.

2. Incorrect or missing ARIA role The tree shows role="generic" or a non-existent role value. A screen reader receives the element’s existence but no information about what it does or how to interact with it. Fix: use native HTML elements where possible (<button>, <a>, <nav>). If a custom element is required, assign a valid WAI-ARIA role. WCAG criterion: 4.1.2.

3. Decorative image still present in the tree An image used for layout or visual decoration appears in the tree without a name. Screen readers attempt to announce it — often reading the raw file name. Fix: add alt="" to decorative images. For SVGs used as content, add aria-hidden="true". WCAG criterion: 1.1.1.

4. Heading hierarchy gap The tree shows <h4> immediately after <h2>, or <h2> with no preceding <h1>. Screen reader users navigating by heading lose the document’s logical structure. Fix: use heading levels sequentially. WCAG criterion: 1.3.1.

5. Interactive element absent from the tree A custom dropdown or slider built with <div> and a click handler does not appear as interactive in the tree. Keyboard users cannot reach it. Screen readers cannot identify it. Fix: replace with native HTML controls, or add role, tabindex="0", and keyboard event handlers. WCAG criteria: 4.1.2, 2.1.1.

Checkout and Payment Accessibility covers checkout flows specifically — the highest-stakes location for these interactive element failures, where a missing computed name on a payment button creates both an accessibility barrier and a transaction failure.

---

Frequently Asked Questions

Is the accessibility tree the same as the DOM?

No. The DOM is the complete structural representation of a page, including all elements regardless of semantic meaning. The accessibility tree is a filtered subset: only elements meaningful to assistive technology are included, and their properties are calculated from HTML semantics, ARIA attributes, and CSS, not read directly from the DOM.

Can CSS break the accessibility tree?

Yes. display: none and visibility: hidden remove elements from the accessibility tree entirely. aria-hidden="true" also removes an element from the tree while leaving it in the DOM. The important exception is opacity: 0: an element hidden this way stays in the tree and remains fully reachable by screen readers and keyboard users, even though it is visually invisible.

Does the accessibility tree affect SEO?

Indirectly. Search engines increasingly parse page structure in ways that parallel how screen readers do. Proper semantic HTML that produces a clean accessibility tree also produces cleaner crawlable structure. Logical heading hierarchies, named links, and properly labeled form fields benefit both assistive technology users and search engine crawlers reading page content programmatically.

---

Automated scanners (including this one) query the accessibility tree programmatically, the same way a screen reader does. They do not analyze visual layout. That is why a button can look correct visually and still carry an empty computed name that no visual check would catch. DevTools inspection is the manual version of what scanners run at scale. Start with the five errors above, check the computed name panel for every interactive element on your highest-traffic pages, and treat any empty name field as a critical failure that needs a fix before the next deploy.

This article is for general informational purposes and is not legal advice.