When we work with accessibility tools, we naturally build mental models to help us understand what’s happening under the hood.
Many of these models are reasonable, widely shared, and even reinforced by browser tooling and documentation. But some of them are also a little too neat.
Below are three accessibility assumptions that can quietly shape how we test, debug, and interpret results.
1. The DOM we see in DevTools is the real DOM
The assumption
The DOM shown in browser DevTools is the actual DOM. It represents a stable tree of elements that reflects what the browser is working with at any given moment.
The reality
- The DevTools DOM is a developer-facing representation, not the browser’s internal source of truth.
- It is simplified and reconciled to make it easier to inspect.
- The DOM is constantly mutating as scripts run, styles resolve, users interact, and layouts update.
- What we see is a snapshot only.
For a deeper dive
2. The accessibility tree we see is an accurate picture of what assistive technologies receive
The assumption
The accessibility tree shown in browser tooling accurately represents what is exposed to assistive technologies, and inspecting it tells us what screen readers and other AT will perceive.
The reality
- The tree we see is a debugging view, not the full internal model.
- Browsers maintain more than one accessibility-related representation.
- Some parts of the accessibility pipeline are implicit and not exposed.
- What reaches platform APIs and assistive technologies is filtered, reshaped, and context-dependent.
For a deeper dive
3. Screen reader output is a clean, ordered sequence of events
The assumption
Changes in the DOM or accessibility tree result in predictable, ordered announcements from screen readers, with each event mapping cleanly to a spoken output.
The reality
- Screen readers operate speech queues, not direct event streams.
- Announcements can be merged, interrupted, delayed, or dropped.
- Timing, verbosity settings, and user interaction all influence output.
- What is spoken is often a priority-driven outcome, not a precise reflection of events.
For a deeper dive
Why is it important to unpack these assumptions?
The DOM and accessibility tree are reliable guides most of the time, until you hit the edges where they stop being authoritative.
Understanding the nuances of the DOM, accessibility tree, and speech queue can help when testing and interpreting results.