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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
A proper