How to Inspect the Accessibility Tree and ARIA Roles in Safari Web Inspector

Modern web accessibility standards—such as the Web Content Accessibility Guidelines (WCAG 2.2) and Section 508—require that digital interfaces provide semantic, machine-readable representations for assistive technologies like screen readers. When a browser parses an HTML document, it creates two parallel internal data structures: the standard Document Object Model (DOM) tree used for visual CSS layout rendering, and the Accessibility Tree used by assistive technologies (such as Apple VoiceOver on macOS and iOS). While the visual DOM may look complete, missing Accessible Rich Internet Applications (ARIA) attributes or incorrect semantic roles can leave interactive widgets completely invisible to screen reader users. This article explains how to inspect the computed Accessibility Tree, audit AXObject attributes, verify accessible names, and debug ARIA roles in Safari Web Inspector.

Understanding the Accessibility Tree and ARIA Mapping in WebKit

WebKit builds the Accessibility Tree by translating HTML elements, ARIA attributes, and computed text nodes into a hierarchical tree of accessibility objects (known internally as AXObject in WebKit):

• Semantic HTML Mapping: Native semantic elements automatically receive rich accessibility metadata (e.g. <button> maps to role button, <nav> maps to navigation landmark, <input type="checkbox"> exposes checkable states).
• Accessible Name Computation: WebKit calculates an element’s accessible name by evaluating an ordered hierarchy of text sources: aria-labelledby, aria-label, native labeling (such as <label for="...">), and inner text or alt/title attributes.
• ARIA Roles and States: Where generic container elements (such as <div> or <span>) are used to construct custom interactive components (tabs, accordions, dialogs), ARIA attributes (role="tab", aria-selected="true", aria-expanded="false") bridge the gap by explicitly defining role and state.
• Subtree Pruning: Elements marked with aria-hidden="true", hidden, or display: none are excluded from the accessibility tree, preventing screen readers from reading background content.

Opening Safari Web Inspector and Accessing Accessibility Tools

To inspect accessibility structures on macOS:

1. Verify that developer features are enabled in Safari > Settings > Advanced by checking Show features for web developers.
2. Navigate to your target website or web application.
3. Right-click the element you wish to evaluate and select Inspect Element.
4. Web Inspector opens to the Elements panel, highlighting the DOM node in the central DOM tree.
5. In the right-hand inspection sidebar, locate the tabs (Styles, Computed, Layers, etc.) and click on the Node Details / Accessibility tab (represented by the universal human accessibility figure icon).

Inspecting Node Accessibility Attributes and Roles

Selecting any node in the DOM tree populates the Accessibility panel with the calculated accessibility profile for that element:

1. Role: Displays the computed accessibility role recognized by Apple VoiceOver (e.g. Button, Heading, Link, Tab, Landmark Navigation). If a clickable <div> displays role Generic Container, it lacks semantic meaning and requires role="button".
2. Label / Accessible Name: Shows the exact string read aloud when a screen reader focuses on the element. WebKit details how the name was derived (for example, confirming that text was extracted from aria-label rather than placeholder text).
3. Description / Help: Displays secondary assistive text provided via aria-describedby or native title attributes.
4. States and Properties: Lists active boolean states:
   • Focusable and Focused: Confirms whether the element can receive keyboard focus via Tab navigation.
   • Expanded (aria-expanded): Verifies whether an accordion or dropdown menu correctly reports its open/collapsed state.
   • Checked / Selected: Indicates selection states for checkboxes, radio buttons, and tabs.
   • Disabled: Confirms whether disabled controls are communicated to assistive tech.

Navigating the Full Accessibility Tree Hierarchy

Beyond evaluating individual elements in isolation, reviewing parent-child relationships across the complete accessibility hierarchy is crucial for ensuring that screen reader users can navigate landmark regions smoothly:

1. In the Accessibility sidebar, expand the Accessibility Hierarchy tree.
2. Observe how the document is structured into landmark containers (banner, main, navigation, contentinfo).
3. Verify that interactive child items (such as list items inside a list, or tabs within a tablist) maintain proper hierarchical relationships.
4. Check for unwanted elements that clutter navigation. If decorative icons or background illustrations appear in the accessibility tree, add aria-hidden="true" to suppress them.

Testing Keyboard Focus and VoiceOver Simulation

While Web Inspector visualizes the computed accessibility tree, developers should validate the experience interactively:

• Keyboard Tab Navigation: Press the Tab key across the webpage to verify that all interactive controls receive visible focus indicators and follow a logical reading order.
• VoiceOver Testing: Press Cmd + F5 on macOS to launch VoiceOver. Navigate through your interface using Control + Option + Arrow Keys, confirming that the speech output matches the labels and roles verified in Safari Web Inspector.

By regularly auditing the Accessibility Tree and ARIA roles in Safari Web Inspector, web developers ensure their websites deliver accessible, compliant, and inclusive user experiences across all devices.