The document is a tree, and the pixels are not the interface

An interface looks like what a person sees: a button in a panel, a field with a label, a link made of words. None of that is the object the program holds. The program holds a tree of nodes. Everything a person receives, the picture on screen and the words a screen reader speaks, is derived from that tree by machinery the programmer did not write. This unit argues that the document object model is a logical model, not the interface itself, and that the browser builds more than one thing from it. Because the browser derives the trees a person actually gets, a control in the markup can be absent from the interface a user receives. The strongest counter-argument, taken up below, is that the derivation is not only lossy. A name can be computed from an element's content or context, so an unlabelled control is not always unreachable, and the large label counts come from automated checks.

The mistake this unit targets is a developer who inspects a page, sees a control, and concludes that every user will meet it. In the one view that developer has, markup and experience look identical. The distance between them follows from turning one logical structure into several, for several ways of perceiving. Unit 5 asks how to keep that tree apart from the state it shows.

The document is a logical tree, and the tree is not the state

The model is specified. The DOM Standard defines the document object model as a platform-neutral model for events, aborting activities and node trees. A tree, it says, is a finite hierarchical structure in which each object has a parent and an ordered set of children (WHATWG, 2026). A document is one such tree, and the standard defines how nodes are created, inserted, removed and queried. MDN adds the teaching form. The DOM represents a document with a logical tree, each branch ends in a node, and each node contains objects (Mozilla Foundation, 2026). The tree is a set of named relationships, and any drawing is computed from it afterwards.

The browser derives the trees a person receives

The browser's own architecture shows the derivation. Grosskurth and Godfrey derived a reference architecture from two open-source browsers, validated against further implementations. It describes eight subsystems, including a parser, a rendering engine and a script interpreter (Grosskurth and Godfrey, 2005). Two of them do the work this unit cares about. The parser turns a document into a document object model tree, and the rendering engine turns a document into a visual representation, calculating layout as content changes (Grosskurth and Godfrey, 2005). Read the sequence as a pipeline, and the thesis follows: the tree is an input, and what a person sees is an output. Between the model the program holds and the experience a person has stands a derivation, and a derivation is where things can be lost or changed.

The accessibility tree is a second derivation

The visual rendering is one derived tree. There is another. MDN describes the accessibility tree as a structure the browser creates from the document object model. Platform-specific accessibility APIs then use that structure to give assistive technologies, such as screen readers, a representation they can understand (Mozilla Foundation, 2026). Each object carries a name, a description, a role and a state, so a link can be followed and a text input typed into (Mozilla Foundation, 2026). WAI-ARIA 1.2 defines the role vocabulary, an ontology of roles, states and properties that describe interface elements to assistive technology (W3C, 2023b). The accessible interface is a derived artefact with its own vocabulary, built from the tree and so capable of differing from it.

The difference is visible in a single control. A button element carries the role and the name the derived tree needs, so a screen reader can announce it and activate it. A plain container element given the same click handler carries neither by default. The derived tree holds a node with no role and no name, so the control that looks identical on screen is absent from the interface a screen-reader user receives. What survives the derivation is what the element's semantics supply, not what the author intended the picture to mean. A supplied name reaches other readers too, since a text label serves a person with low literacy who cannot decode the icon.

What the derived tree carries, and what it can lose

If the accessibility tree is derived, a control present in the markup can be missing from it, and large-scale evidence says this happens often. Ross and colleagues analysed 5,753 free Android applications for the labelling of image-based buttons. In 45.9 per cent of them, at least nine in ten of the assessed buttons carried no label at all (Ross et al., 2018). Floating action buttons were worst: 92.0 per cent lacked a label, against 54.7 per cent of image buttons and 86.3 per cent of clickable images. An unlabelled button is not absent from the application; it is absent from the interface a screen-reader user receives, because the name the derived tree would carry was never supplied.

The user side of the gap is documented. Lazar and colleagues surveyed 100 blind users about the frustrations they met on the web, and grouped their accounts into recurring categories (Lazar et al., 2007). The method is users' own reports, so it supplies the other end of the pipeline: not what the tree contains, but what a person can reach. Automated analysis can say that a name is missing. It cannot say whether a name, once present, tells the user what the control does. That study settled it by manual inspection of labels such as image and desc. Automated analysis is a floor, not a ceiling (Ross et al., 2018).

Contested question: is conformance the same as access?

The literature agrees that a derived interface can differ from its source, and disagrees about what counts as success. The standards camp holds that a shared, testable target is the right one. WCAG 2.2 states its success criteria as testable statements under four principles: perceivable, operable, understandable and robust (W3C, 2023a). The strength of that position is auditability at scale, which is what makes WebAIM's census of a million home pages possible (WebAIM, 2026). Its limit is inherited from the same property: a testable statement measures the page, not the person.

The use camp holds that meeting the standard is not the same as removing barriers, and its evidence comes from users rather than from pages. Power and colleagues ran task-based evaluations with 32 blind users across 16 websites and recorded 1,383 user problems. Only 50.4 per cent of those problems were covered by WCAG 2.0 criteria. Where a criterion was covered, 16.7 per cent of the websites had implemented the recommended technique and the problem remained (Power et al., 2012). That is the unit's strongest single result, and it is one study of 16 sites judged against WCAG 2.0, before WCAG 2.2. Vigo and Harper add a taxonomy rather than a rate: 17 coping tactics across 129 situations, marking the problems a page created rather than conformance (Vigo and Harper, 2013). On this reading accessibility is a property of use.

A third strand explains why the argument is hard to close. Petrie, Savva and Power analysed 50 definitions of web accessibility and extracted six core concepts. They proposed a unified definition: the ability of people, particularly disabled and older people, to use websites across a range of contexts, including assistive technologies (Petrie et al., 2015). If the term is used in several ways, the two camps are measuring different things. What would settle it is a comparison the field has not run. Take one interface, hold the task constant, and compare blind users' task success and the number of problems they meet against the page's conformance level, rather than against criteria passed. Until then a designer should treat conformance as a floor, inspect the computed accessibility tree for the control in question, and record a user's problem as a defect even where every criterion is met.

A tree for a user whose capability has changed

The contested section treats accessibility as fixed. The derived-tree model shows that it is not. Yesilada and colleagues studied users of small devices. Eight of the eleven input error types seen in desktop users with motor impairments also appeared in small-device users. Two more came from the screen size: key ambiguity and landing errors (Yesilada et al., 2010). They call the result situational impairment: entering text and hitting targets on a small device degrades performance like a permanent motor impairment (Yesilada et al., 2010). The person a derived tree must serve can change from moment to moment, so the same control can be adequate in one context and not another.

Where the argument is heading

Three lines of work name the direction. Ara, Sik-Lanyi and Kelemen reviewed 92 primary studies of accessibility evaluation. Automated evaluation dominated, they found, while treatment of users was uneven. That locates the weakness where this unit draws it, between the tree and the person's experience (Ara et al., 2024). Campoverde-Molina, Lujan-Mora and Valverde reviewed 42 studies covering 9,140 university websites in 67 countries, and found widespread problems, most often in adaptability, keyboard access and text alternatives (Campoverde-Molina et al., 2021). WebAIM's census sharpens the picture: in the analysis published in February 2026, 95.9 per cent of the top million home pages carried detectable WCAG 2.2 A/AA failures, averaging 56.1 errors per page (WebAIM, 2026). The direction of travel is toward exposing the computed accessibility tree to tools and authors, so that the derived interface becomes as inspectable as the source.

The sources this unit rests on

• WHATWG. (2026). DOM Standard. Living Standard. https://dom.spec.whatwg.org/ Defines the document object model as a platform-neutral model for events, aborting activities and node trees. The normative definition of the tree the unit contrasts with what a user receives.
• Mozilla Foundation. (2026). Document Object Model and accessibility tree. MDN Web Docs. https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model Describes the DOM as a logical tree and the accessibility tree as a structure derived from it for assistive technologies, carrying name, description, role and state. The second-derivation claim.
• W3C. (2023a). Web Content Accessibility Guidelines (WCAG) 2.2. W3C Recommendation. https://www.w3.org/TR/WCAG22/ States the success criteria a conforming page must meet under perceivable, operable, understandable and robust. The conformance target whose limits the contested section examines.
• W3C. (2023b). Accessible Rich Internet Applications (WAI-ARIA) 1.2. W3C Recommendation. https://www.w3.org/TR/wai-aria-1.2/ Provides an ontology of roles, states and properties conveying semantics to assistive technology, and defines how author-supplied semantics relate to native markup. The vocabulary of the derived accessible interface.
• WebAIM. (2026). The WebAIM Million: the 2026 report on the accessibility of the top 1,000,000 home pages. https://webaim.org/projects/million/ The analysis published in February 2026 reports that 95.9 per cent of the top million home pages carried detectable WCAG 2 A/AA failures, averaging 56.1 errors per page, and states that all automated tools, including the one used, under-detect. The current scale of the gap and its measurement limits. The earlier figures of 94.8 per cent and 51 errors per page are the February 2025 edition of the same report, at https://webaim.org/projects/million/2025.
• Power, C., Freire, A., Petrie, H. and Swallow, D. (2012). Guidelines are only half of the story: accessibility problems encountered by blind users on the web. CHI 12, 433-442. doi:10.1145/2207676.2207736 Ran task-based evaluations with 32 blind users on 16 websites, recorded 1,383 problems, and found only 50.4 per cent were covered by WCAG 2.0, with 16.7 per cent of websites still failing after implementing the recommended techniques. The central evidence that conformance is not access.
• Lazar, J., Allen, A., Kleinman, J. and Malarkey, C. (2007). What frustrates screen reader users on the web: a study of 100 blind users. International Journal of Human-Computer Interaction 22(3), 247-269. doi:10.1080/10447310709336964 Surveyed 100 blind users about their frustrations on the web and grouped the accounts into categories of difficulty. User-side evidence for what the derived interface must carry.
• Grosskurth, A. and Godfrey, M. W. (2005). A reference architecture for web browsers. ICSM 05, 661-664. doi:10.1109/ICSM.2005.13 Derived a reference architecture from two open-source browsers, validated against further implementations, with eight subsystems including a parser producing a document tree and a rendering engine producing a visual representation. The tree as an input to a derivation.
• Vigo, M. and Harper, S. (2013). Coping tactics employed by visually disabled users on the web. International Journal of Human-Computer Studies 71(11), 1013-1025. doi:10.1016/j.ijhcs.2013.08.002 Analysed the interaction of 24 users across two datasets, identified 129 problematic situations and 17 coping tactics, and reframed accessibility as a property of use. Barriers persist after the checklist is met.
• Petrie, H., Savva, A. and Power, C. (2015). Towards a unified definition of web accessibility. W4A 15, 35. doi:10.1145/2745555.2746653 Analysed 50 definitions of web accessibility, extracted six core concepts, and proposed a unified definition combining use across contexts, including assistive technologies. The term itself is used inconsistently.
• Ross, A. S., Zhang, X., Fogarty, J. and Wobbrock, J. O. (2018). Examining image-based button labelling for accessibility in Android apps through large-scale analysis. ASSETS 18, 119-130. doi:10.1145/3234695.3236364 Analysed 5,753 free Android apps and found 45.9 per cent had fewer than 10 per cent of assessed image-based buttons labelled, with 92.0 per cent of floating action buttons missing labels. The same failure appears in native applications.
• Yesilada, Y., Harper, S., Chen, T. and Trewin, S. (2010). Small-device users situationally impaired by input. Computers in Human Behaviour 26(3), 427-435. doi:10.1016/j.chb.2009.12.001 Found that eight of eleven motor-impairment input errors recurred in small-device users, plus key ambiguity and landing errors, and introduced situational impairment. The user a derived tree must serve can change with context.
• Ara, J., Sik-Lanyi, C. and Kelemen, A. (2024). Accessibility engineering in web evaluation process: a systematic literature review. Universal Access in the Information Society 23, 653-686. doi:10.1007/s10209-023-00967-2 Reviewed 92 primary studies from 2010 to 2021 and found automated evaluation dominant with uneven treatment of users. Locates the field's weakness where the tree meets the person.
• Campoverde-Molina, M., Lujan-Mora, S. and Valverde, L. (2021). Accessibility of university websites worldwide: a systematic literature review. Universal Access in the Information Society 22, 133-168. doi:10.1007/s10209-021-00825-z Reviewed 42 studies covering 9,140 universities in 67 countries and found widespread accessibility problems, most often in adaptability, keyboard access and text alternatives. Large-scale evidence that the gap remains.