Чтение дерева доступности для отладки ARIA

The browser builds an accessibility tree from your DOM. It is the stripped-down version that screen readers actually read.

Looking at the tree shows the truth: the real name, role, and state of an element, not what you hoped your markup produced.

In Chrome, open DevTools and pick the Accessibility pane in the Elements panel. Select any node to inspect its computed a11y data.

The pane shows the element's computed role and name plus its states. This is exactly what assistive tech will announce.

Firefox ships an Accessibility inspector as its own DevTools tab, with a handy check for common contrast and naming issues.

The most common bug the tree reveals is a control with an empty name. An icon button shows no name, so users hear only button.

If you expected a button but the tree says generic, your role never applied. Fix the markup before adding more ARIA on top.

Toggle your widget and watch the tree. If aria-expanded does not flip in the pane, your JavaScript is not syncing the state.

An element set to aria-hidden drops out of the tree entirely. Use this to confirm decorative content is correctly skipped.

The tree shows intent, but a real screen reader shows experience. Use the tree to debug, then confirm with NVDA or VoiceOver.

Build the habit: change markup, reselect the node, read its name, role, and state. Tight loops catch ARIA mistakes fast.

Your custom button reads as just button with no label. Where do you confirm the missing name?

You learned the accessibility tree is what AT really reads. Inspect it in DevTools to verify names, roles, and states, then confirm with a real screen reader. 🔍