How screen readers understand your page
Have you ever wondered how assistive technology like a screen reader decides what to announce to a user? The short answer is that it depends entirely on the code you write. When you mark up your page with semantic HTML, you give assistive technology the information it needs to present your interface meaningfully. But what exactly are semantics, and how does a screen reader put them to use?
What semantics mean for non-visual users
An affordance is any object that suggests how it should be used. A teapot is a classic example: its handle and spout make its operation obvious without an instruction manual, because you've seen similar objects before. When you build a graphical user interface, you often use CSS to create those visual affordances—a button gets a drop shadow and border so it reads as something you can press.
But for users who can't see the screen, those visual cues are lost. To bridge that gap, your interface needs to convey the same affordances non-visually to assistive technology. That non-visual exposure of an element's affordances is called its semantics.
Semantic HTML is the shortcut
The most reliable way to convey proper semantics is to use semantically rich HTML elements. It's possible with CSS to make a <div> look exactly like a <button>, but the two behave very differently for a screen reader. A <div> is a generic grouping element, so a screen reader will only announce the text it contains. A <button>, by contrast, is announced as a "button"—a much stronger signal that the user can interact with it.
When you're tempted to build a custom interactive control, the best solution is usually to avoid it altogether. If a <div> is acting like a button, replace it with a real <button>.
Semantic properties and the accessibility tree
In general, every HTML element can be described by a few core semantic properties:
- A role or type
- A name
- A value (optional)
- A state (optional)
The role describes what kind of element it is—"button," "input," or just "group" for generic containers like div and span. The name is the computed label. Screen readers typically announce the name followed by the role, such as "Sign up, button." The algorithm that computes the name considers text content inside the element, attributes like title or placeholder, association with a real <label> element, and ARIA attributes such as aria-label or aria-labelledby.
Some elements may also carry a value. For example, an <input type="text"> has a value that reflects whatever the user has typed. Others have a state conveying current status—a <select> element, for instance, is either in an expanded or collapsed state depending on whether it's open.
How the accessibility tree is built
For every node in the DOM, the browser decides whether it's semantically "interesting" enough to add to the accessibility tree. When a screen reader presents an alternative UI, it does so by walking that tree. If you want to inspect an element's semantic properties or explore its position in that tree, Chrome DevTools lets you do so directly.
Next steps
Once you understand how semantics drive screen reader navigation, it changes how you look at the pages you build. The next step is to think about the overall outline of a page and how it can be conveyed through effective headings and landmarks.
