Element choice is interface design: meaning and the accessibility tree

A page is not one artefact. A browser renders the document into pixels, and at the same time into a second structure that screen readers and voice control read. That second structure is derived from the elements an author chooses, so choosing an element is an interface decision. A div styled as a button is a different interface from a button, however identical it looks.

The claim rests on a mechanism rather than a preference. A browser does not infer what a control is from its appearance: it reads the meaning the markup supplies, and it computes a role, a name and a state that a screen reader announces. An author who supplies only the appearance has left the announced interface to whoever wrote the styling. The strongest counter to this unit's thesis is that a correct tree is a precondition rather than a deliverable. Leuthold, Bargas-Avila and Opwis (2008) improved the structure of an interface and found no gain in navigation, because the labels still carried the meaning. Unit 1 set out the contract. This unit takes the part an author writes, the markup a browser reads twice.

Two trees grow from one document

The living HTML standard defines what each element means and the processing rules a conforming user agent must follow (WHATWG, n.d.). The browser uses those rules to build the accessibility tree. That second tree mirrors the document, but it carries what assistive technology needs: the roles, names, states and values of the things on the page (Mozilla Foundation, n.d.).

Three properties decide what a screen reader announces. The role says what the thing is. The name says what it is called. The state says whether it is pressed, checked, expanded or disabled (W3C, 2023). For a native element the browser supplies all three from the element itself.

Work the name on one control. A button whose visible label is the word Search is announced with the role button and the name Search. Move the same word into a div. It is then announced as text inside a generic container, with no name and no role to press. The browser computes the difference from the element, not the styling.

What a native element gives away for nothing

A div with a click handler looks identical to a button, and it fails in four ways. It is not reachable with the Tab key. It has no keyboard activation. It has no accessible name unless one is supplied separately. It has no disabled state to announce. ARIA (Accessible Rich Internet Applications) is the mechanism for supplying such properties to a custom control (W3C, 2023).

Supplying a role is only a beginning, because a role is a promise about behaviour. The Authoring Practices Guide states the keyboard contract each widget pattern must implement (W3C Web Accessibility Initiative, n.d.). A custom combobox must open its popup on a downward arrow, dismiss it on Escape without changing the value, and accept a highlighted suggestion on Enter. A native control ships with that contract met, while a div must reproduce it by hand. The accessible name is computed by a defined algorithm over the element's own text and associated properties (W3C, n.d.). An icon-only control whose label is drawn in CSS therefore has an empty name rather than no label.

Choosing an element is choosing an interface

Put the mechanism to work on one control, an icon that submits a search. Built as a styled div with the icon drawn in CSS, it has no Tab stop, no keyboard activation, no name and no state. Built as a button with an accessible name, it arrives with a role, a name, a focus stop and keyboard activation supplied by the element. The author has built a different control, and the element choice decided the difference, not the stylesheet.

The announced page is a different artefact

If the two trees diverge, a page that passes a visual inspection has been inspected only once. Asakawa (2005) surveyed what the web is like for a user who cannot see it. The survey reported pages carrying alternative text and skip links that are present but inappropriate, so the page is compliant on paper and unusable in practice. Kane, Shulman, Shockley and Ladner (2007) graded the home pages of the world's top universities, and they found widespread failures among sites whose audience has a right of access.

The platform can be patched after the fact, and the history shows the cost. Takagi and Asakawa (2000) built a transcoding proxy that restructures existing pages before they reach a nonvisual user. They were responding to an authoring trend of crowding many functions into one page. A repair at the proxy sits outside the document. It must be maintained for every page it touches, and it cannot supply meaning the markup never carried.

The user evidence is the check on the mechanism

The user evidence shows which differences people actually meet. Lazar, Allen, Kleinman and Malarkey (2007) collected time diaries from 100 blind users, recording their frustrations on the web. The most frequent causes were page layout producing confusing screen reader feedback, conflict between screen reader and application, poorly designed or unlabelled forms, and missing alternative text.

Two studies show that structure and usability are not the same quantity. Petrie and Kheir (2007) asked whether disabled and non-disabled users meet the same problems. Testing two websites with six blind and six sighted participants, they found the problems overlapped only partly, so a remedy for one group is not automatically a remedy for the other. Leuthold, Bargas-Avila and Opwis (2008) built an enhanced text interface from nine guidelines and tested it with 39 blind participants on a search task and a navigation task. Search became significantly faster with fewer errors, but navigation did not improve. The authors attribute that to labelling rather than to the interface.

Leporini and Paterno (2008) reached a qualified conclusion of the same shape. They derived fifteen criteria intended to integrate accessibility with usability, then ran two user tests asking whether applying the criteria improved task performance. Criteria that treated the two together helped, while accessibility alone did not guarantee usability.

Contested question: is the accessibility tree the deliverable, or only a precondition?

The literature disagrees, and both positions sit in this unit's sources. The normative sources and the practitioner guide treat the tree as the deliverable: if the role, name and state are correct and the keyboard contract is met, the interface has been built, and the remaining work is conformance testing (W3C, 2023; W3C Web Accessibility Initiative, n.d.). The user studies hold that the tree is a precondition rather than an achievement. A better structure did not improve navigation when the labels were meaningless (Leuthold et al., 2008). The problems the two user groups meet differ, so a structurally correct page can still miss the users it was meant to include (Petrie and Kheir, 2007).

Brajnik, Yesilada and Harper (2010) complicate the first position from inside it. They tested the testers, asking whether knowledgeable inspectors agree on whether WCAG 2.0 criteria have been met. Experts and non-experts evaluated four complex pages. Agreement fell short of the level the guidelines themselves assume, and expertise affected the outcome. The specification's own mechanism for deciding conformance is therefore less reliable than the specification presupposes.

The two positions make different predictions, and need different evidence. If the tree is the deliverable, a control with correct role, name and state should perform as well as a native control once those properties are supplied. If the tree is only a precondition, task outcomes should change when the names vary and the tree is held constant, because the labels carry the meaning the tree merely exposes. What would settle the question is a study that fixes the accessibility properties of two interfaces, varies only whether the names make sense, and measures task success rather than conformance. Leuthold's navigation result is the closest evidence, and it points to the second position. It is one study on one website, so the question stays open.

While the question is open, a designer should treat a correct role, name and state as the entry condition rather than the finish. Reach for the native element first, and test the interface with the names a reader will actually meet rather than the markup alone. Where a custom control is unavoidable, reproduce the keyboard contract the widget pattern specifies. Then check the task with a screen reader user, because conformance and task success can diverge on the same page.

Where the argument is heading

The recent work points away from asking whether the tree is present, and towards measuring what the tree costs to use. Buzzi, Leporini and Pieriboni (2026) present a tool that estimates the reading effort a page imposes on a screen reader user from structural metrics. Rohani Ghahari and colleagues (2012) had already shown the structure used as a resource rather than a label, designing topic- and list-based back navigation so a screen reader user can return to earlier content without relistening. Once built, the tree becomes raw material for reducing the effort of an interface rather than a checklist.

The sources this unit rests on

• WHATWG (n.d.). HTML Standard. Web Hypertext Application Technology Working Group. https://html.spec.whatwg.org/multipage/ It defines the meaning of each element and the processing rules a user agent must follow. It is normative with no user evidence, so it fixes what an element means rather than what follows from choosing it.
• Mozilla Foundation (n.d.). Accessibility tree. MDN Web Docs. https://developer.mozilla.org/en-US/docs/Glossary/Accessibility_tree It explains the second tree browsers build from the document for assistive technology. It describes the platform's behaviour rather than outcomes, and it is the reference for the tree this unit's argument turns on.
• W3C (2023). Accessible Rich Internet Applications (WAI-ARIA) 1.2. W3C Recommendation, 6 June 2023. https://www.w3.org/TR/wai-aria-1.2/ It defines the roles, states and properties custom controls expose, and the rules for their use. It is normative with no user evidence, so it says what a control must announce, not whether that works.
• W3C Web Accessibility Initiative (n.d.). ARIA Authoring Practices Guide (APG). https://www.w3.org/WAI/ARIA/apg/ The guide gives design patterns for common widgets and states the keyboard interaction each must implement. It demonstrates implementation rather than testing with users, and it shows a role without behaviour is not a control.
• W3C (n.d.). Accessible Name and Description Computation 1.2. W3C Working Draft, 21 October 2026. https://www.w3.org/TR/accname-1.2/ It specifies the algorithm by which a user agent computes an accessible name and description. Being normative, it settles why an unnamed control is defective rather than merely unstyled.
• Asakawa, C. (2005). What's the web like if you can't see it? In Proceedings of the 2005 International Cross-Disciplinary Workshop on Web Accessibility (W4A). doi:10.1145/1061811.1061813 Asakawa surveys what the web is like for a user who cannot see it and reports pages that are compliant yet unusable, with inappropriate alternative text and broken skip links that do not work. It is a synthesis rather than a new experiment.
• Kane, S. K., Shulman, J. A., Shockley, T. J. and Ladner, R. E. (2007). A web accessibility report card for top international university web sites. ASSETS '07. doi:10.1145/1243441.1243472 The authors audited and graded the home pages of top international university web sites and found widespread accessibility failures. It is the inspection evidence that semantic failure is common even where the audience is known and the duty is clear, though it is an audit rather than a user study.
• Takagi, H. and Asakawa, C. (2000). Transcoding proxy for nonvisual web access. ASSETS '00. doi:10.1145/354324.354371 They build a proxy that restructures complex existing pages for nonvisual access, responding to an authoring trend of crowding many functions into one page. It is a repair strategy rather than a report of user outcomes, and it shows how far the platform is patched after the fact.
• Lazar, J., Allen, A., Kleinman, J. and Malarkey, C. (2007). What Frustrates Screen Reader Users on the Web: A Study of 100 Blind Users. Int. J. Human-Computer Interaction. doi:10.1080/10447310709336964 They collected time diaries from 100 blind users recording their frustrations on the web. The top causes were confusing layout feedback, screen reader conflicts, unlabelled forms and missing alternative text.
• Petrie, H. and Kheir, O. (2007). The relationship between accessibility and usability of websites. CHI '07. doi:10.1145/1240624.1240688 The study asked whether disabled and non-disabled users meet the same problems, testing two sites with six blind and six sighted participants. The problems overlapped only partly, so a fix for one group is not automatically a fix for the other.
• Leuthold, S., Bargas-Avila, J. A. and Opwis, K. (2008). Beyond web content accessibility guidelines: Design of enhanced text user interfaces for blind internet users. Int. J. Human-Computer Studies. doi:10.1016/j.ijhcs.2007.10.006 They built an enhanced text interface from nine guidelines and tested it with 39 blind participants on search and navigation tasks. Search became significantly faster with fewer errors, but navigation did not improve, which the authors attribute to labelling.
• Leporini, B. and Paterno, F. (2008). Applying Web Usability Criteria for Vision-Impaired Users: Does It Really Improve Task Performance? Int. J. Human-Computer Interaction. doi:10.1080/10447310701771472 They derived fifteen criteria integrating accessibility with usability and ran two user tests asking whether applying them improved task performance. Criteria integrating the two helped, while accessibility alone did not guarantee usability.
• Brajnik, G., Yesilada, Y. and Harper, S. (2010). Testability and validity of WCAG 2.0. ASSETS '10. doi:10.1145/1878803.1878813 They tested the testers, asking whether knowledgeable inspectors agree that WCAG 2.0 criteria are met, with experts and non-experts evaluating four complex pages. Agreement fell short of the level the guidelines assume, and expertise affected the outcome.
• Rohani Ghahari, R., Ferati, M., Yang, T. and Bolchini, D. (2012). Back navigation shortcuts for screen reader users. ASSETS '12. doi:10.1145/2384916.2384918 They designed topic- and list-based back navigation so screen reader users can return to earlier content without relistening, validated with ten participants at a school for the blind. The shortcuts used structure the page already carried.
• Buzzi, M., Leporini, B. and Pieriboni, G. (2026). Estimating Reading Effort for Screen Reader Users: A Simple Tool to Support Web Accessibility Awareness. W4A '26. doi:10.1145/3800424.3800443 The tool estimates the reading effort a page imposes on a screen reader user from metrics such as word count, reading time, heading structure and interactive elements. It moves the question from presence of the tree to its cost.