Foundations of the Accessibility Tree: How Machines See

Why the Designer should know the Accessibility Tree?

As designers, we often focus on the Visual DOM (colors, shapes, positions). However, for blind or visually impaired users, your design is only what the Accessibility Tree says it is.

If a button in your design looks like a blue arrow but has no name in the Accessibility Tree, for a blind person, that button “doesn’t exist” or is useless. Understanding this tree is the key to an accessible handoff to development.

The 4 Pillars of an Accessibility Node

Each element of your interface sent to the tree has four critical properties that you, as a designer, must define:

1. The Role

What is this object? It is the functional purpose of the element.

• Examples: button, checkbox, heading, link, main.
• Importance: Tells the user what they can expect to do with that element.

2. The Name

What is this object called? It is the identifying label.

• Examples: “Submit form,” “Close window,” “Search.”
• Source: Can come from visible text within a button or from an invisible attribute (aria-label).

3. The State

What is the object doing right now?

• Examples: checked, expanded, disabled, focused.
• Importance: Communicates to the user if a menu is open or if a checkbox is checked without needing to see it.

4. The Value

What is the object’s current information?

• Examples: In a slider, the value would be “50%.” In a text input, the value would be what the user has typed.

How to Design for the Accessibility Tree

You, as a product designer, are responsible for orchestrating this “non-visual” experience:

• Define Roles Clearly: If you design something that behaves like a button, make sure to document it as such so developers don’t build it as a simple link or a div.
• Avoid Missing Names: All interactive icons (like the “X” for closing) must have a hidden accessible name. Otherwise, the screen reader will simply say “button” without context.
• Beware of Heading Hierarchy: The tree uses headings (H1, H2, H3) as an index so the user can jump from section to section. If you jump from an H1 to an H4 for aesthetics, you are breaking the index for the blind user.
• Hide what is not necessary: Some visual elements (like decorative icons or ornament lines) only add noise. You can ask developers to hide them from the accessibility tree using aria-hidden="true".

Accessibility Handoff: Your New Task

Instead of delivering only pixels, start delivering Accessibility Intentions. You can use annotations in Figma to indicate what the accessible name of an icon should be or what order the screen reader should follow when navigating the tree.

Mentor’s Tips

• Use the Accessibility Inspector: Open your browser’s DevTools and look for the “Accessibility” tab. You will be able to see the real tree of any web and understand why some fail.
• Golden Rule: If it looks like a button, it should be a button. Don’t try to reinvent standard roles unless strictly necessary.
• Listen to your design: Use a real screen reader (like VoiceOver on Mac or TalkBack on Android) on a web prototype. The experience will open your eyes to the importance of the Accessibility Tree.

Useful Resources and Tools

• W3C: Introduction to the Accessibility Tree
• MDN Web Docs: Understanding the Accessibility Tree
• Deque University: Accessibility Fundamentals
• Articles: A Designer’s Guide to the Accessibility Tree

aria-vs-semantics focus-management screen-reader-testing redlining-specifications