접근성 트리: 스크린 리더가 듣는 내용

The browser turns your DOM into a second structure called the accessibility tree. It is the version assistive tech actually reads.

The accessibility tree is built straight from your HTML. Good semantics in, a rich tree out; div soup in, an empty, useless tree out.

Each node carries a role that says what it is: button, heading, link, list. A real button gets the button role with no effort from you.

Every node also has an accessible name, the text a screen reader speaks. For a button it is usually the visible label inside it.

Interactive nodes expose a state too, like checked, expanded, or disabled. This is how a user hears that a box is already ticked.

So each node boils down to role, name, state, and value. That tiny package is everything a screen reader needs to announce an element.

Anything hidden with display none or aria-hidden is pruned from the tree. If it is not in the tree, a screen reader cannot reach it.

Visual styling like color and size never enters the accessibility tree. A screen reader user gets meaning and structure, not your layout.

A clickable div lands in the tree as a generic node with no role and no name. The user hears nothing useful, even though it looks like a button.

Browser DevTools show the live accessibility tree for any element. It is the fastest way to confirm what a screen reader will actually announce.

The big lesson: your markup is the source of the tree. Fix the HTML and the tree fixes itself, no extra patching required.

Let us test what screen readers hear.

The accessibility tree is your DOM distilled to role, name, state, and value. Fix the markup and the tree follows. Hidden things drop out. 🎉