Every website renders two structures in parallel. One is the DOM, the version developers build and browsers display visually. The other is the accessibility tree, a separate structure built from the same code that assistive technology reads directly. The two are related, but they are not the same thing. In our experience the gap between them is where most accessibility bugs live.
Screen readers like NVDA, JAWS, VoiceOver, and TalkBack don’t read your visual page at all. They read the accessibility tree. If that tree is wrong or incomplete, the user is working from a different, broken version of the page, no matter how clean the design looks, and none of it will look broken to you.
This is usually where the problem gets hard to pin down. A typical case starts with a ticket nobody can reproduce: a user reports that a button doesn’t work, but testing it with a mouse, everything looks fine. It takes a week to figure out the button was never a button to the screen reader, just something styled to look like one. Nobody made a visual mistake. The problem just lives at a layer the usual QA pass never touches.
The accessibility tree is a second, invisible version of your page
The accessibility tree is a structured representation of a webpage that the browser generates specifically for assistive technology. It is derived from the DOM but built as its own object, with role, name, state, and a set of properties for every element on the page.
A proper The same kind of mismatch shows up differently depending on what operating system and browser combination someone is using, which matters if your team only ever tests on one. On Windows, modern screen readers read through UI Automation, Microsoft’s accessibility API and the standard since Windows Vista. On macOS and iOS, Apple built its own version called NSAccessibility. That’s part of why VoiceOver and Safari have historically worked better together than VoiceOver and Chrome on the same machine. On Android, TalkBack reads from the accessibility framework built directly into the SDK. Each platform has its own API, and the browser sits in the middle, translating your HTML into accessible objects that API can understand. When that translation is wrong or incomplete, the screen reader gets noise instead of meaning, and the result can look like a completely different bug depending on which browser and screen reader combination was running at the time. This is also why a fix confirmed working in one combination, say NVDA and Chrome, isn’t automatically working everywhere else. The browser builds the tree, not the screen reader, so the same markup can come out slightly different depending on which browser built it. It’s worth doing, at least for a single component. Chrome DevTools has an Accessibility pane inside the Elements panel that shows you the computed accessible name, role, and properties for whatever you’ve selected. Safari’s Web Inspector has an equivalent Node panel. On native mobile, Xcode’s Accessibility Inspector and Android’s Accessibility Scanner do the same thing for app components. If you want to know whether one specific button or form field is exposing what you think it’s exposing, this is enough to check it yourself. Select the element, open the accessibility pane, and read what’s there. A developer can run this check before opening a pull request. A QA engineer can run it the moment a bug report mentions a screen reader. Either way, it takes two minutes and tells you whether the problem is even in the tree to begin with. What this doesn’t give you is the same thing an automated scanner doesn’t give you either. It tells you what’s structurally present, not whether the experience holds up across an entire flow, on a release that changes weekly. Checking one element in DevTools and running a full screen reader audit against WCAG across a whole product answer two different questions. Teams that catch problems early are usually doing both. Most accessibility tree problems, once identified, are not complicated to fix. A missing label, a wrong role, a Whether you’re the one fixing this or the one explaining to leadership why it’s taking three sprints, a screen reader audit gives both sides the same answer. [[Request your audit.] No. The browser derives it from the DOM but builds it as a separate structure specifically for assistive technology, with its own roles, states, and properties that don’t always match what’s in the DOM. Some of them. Automated tools are good at flagging missing labels or invalid roles in simple cases. Whether a custom component still behaves correctly once a screen reader is interacting with it is a different question that scanners simply can’t answer. Yes. Each browser translates HTML into accessible objects for the operating system’s own accessibility API, and that translation isn’t identical across browsers, which is why a fix verified in one browser and screen reader combination needs to be reverified in others. No. It’s a useful way to verify a single component, but a full audit covers entire user flows across multiple screen reader and browser combinations, checked against WCAG, which is a different scope of work. Written by Kalina Boneva, accessibility QA at Access Drum and a screen reader user with 18 years of hands-on experience with assistive technology. element maps correctly to something a screen reader can identify, announce, and interact with. A The same bug looks different on every platform
You can check your own accessibility tree
from the start. All of these come out of a proper audit and get addressed incrementally without rebuilding anything. The first step is knowing they’re there, which most teams don’t until a real user runs into one, or until a bug report comes in that nobody can reproduce because it only happens with one specific screen reader and browser combination.
FAQ
Is the accessibility tree the same as the DOM?
Can an automated scanner catch accessibility tree problems?
Do different browsers build the accessibility tree differently?
Is checking one element in DevTools the same as an accessibility audit?
