The DOM is the browser's live, in-memory version of your page, a tree of objects it builds by parsing your HTML and then keeps updating as your scripts run. It is what you see in developer tools, and it is usually not what your server sent. That gap is the whole point of the term. Content a script adds after load exists in the DOM and nowhere in your source. That is how an overlay widget changes what a scanner sees while your actual markup stays exactly as broken as it was. Assistive technology mostly does not read the DOM directly. The browser derives the accessibility tree from it, the operating system exposes that, and the screen reader reads whatever arrives at the end of the chain. ARIA calls that the preferred route rather than the only one, and allows software to read the markup straight out of the DOM instead, which is how a tool that reformats a page for easier reading works.
In practice
Two things follow from the DOM being built rather than delivered. The parser is forgiving, so malformed HTML does not stop it. It produces a tree, only not the one you meant, and a good share of structural accessibility bugs are exactly that. And source order in the DOM is what decides the order things get read and, unless something in your code overrides it, the order focus moves. So CSS that visually reorders content can leave a page reading in one sequence while looking like another.
One page can hold several documents. Every iframe is its own document with its own tree, so a page carrying a map, a payment form and a chat widget has four rather than one. A tool that only walks the top document sees none of that content, and neither does anybody auditing by reading your page source.
It is worth knowing which kind of scanner you are running. A tool that drives a real browser measures the finished DOM, scripts and all. A crawler that fetches your source and never runs JavaScript measures something else entirely, and on a modern app that something is close to empty. For a single-page app there is no finished DOM in any case. There is only the DOM at the moment you measured it.
Why it matters
The DOM is what you wrote, and the accessibility tree is what assistive technology receives. Those two can differ a great deal, and the differences are where the confusing bugs live. Hiding something with display:none takes it out of the tree and out of what gets rendered, and leaves it sitting in the DOM where any script can still find it. The aria-hidden attribute takes it out of the tree too, and leaves it not only in the DOM but on the screen, focusable and reachable by keyboard. That is how a reader ends up tabbing to a control their screen reader insists is not there. A presentational role strips an element's own meaning and keeps its contents. Three ways for a thing to be in one structure and missing from the other, and the only way to tell them apart is to look at both.
Why view-source proves nothing
Open your page source and you see what the server sent. Open developer tools and you see what the browser built, after the parser recovered from anything malformed and after every script had its turn. That second one is the page. It is what gets rendered, what gets exposed to assistive technology, and what a real audit is looking at.
Where this shows up on the site
Related terms
- Accessibility treeThe accessibility tree is a second structure the browser builds alongside the DOM, holding one object for every part of your page that has to be exposed to assistive technology.
- Semantic HTMLSemantic HTML means using HTML elements for what they mean rather than for how they look.
- Focus orderFocus order is the sequence focus travels in as you press Tab, and by default it follows the order elements appear in the code rather than the order they appear on screen.
- OverlayAn overlay is a third-party script you add to a site, sold on a subscription, that shows an accessibility toolbar and tries to repair the page automatically as it loads.
Knowing the word is the easy part.
Find out where your own site stands. The free scan checks 10 pages in a real browser against all 90 supported automated rules, separates 27 best-practice checks from its WCAG findings, and names the rule behind every result.