Screen Reader

Screen readers convert the accessibility tree into speech or braille. They depend on semantic HTML, accessible names, and predictable structure rather than visual layout.

Why screen readers matter

When a page has clear headings, landmarks, labels, and button text, users can move quickly and understand context. When those cues are missing, navigation becomes slow, repetitive, and error-prone.

How people navigate with a screen reader

Most screen reader users do not read every word from top to bottom. They commonly jump between:

• headings
• landmarks
• form fields
• links and buttons

This is why semantic structure and explicit names are essential for non-visual navigation.

Code examples

1) Clickable div (hard for screen readers)

<div class="icon-button" onclick="closeDialog()">
  <span class="icon-close"></span>
</div>

Why this is a problem: this control has no native button semantics, no accessible name, and no built-in keyboard behavior.

2) Real button with a clear name

<button type="button" aria-label="Close dialog">
  <span aria-hidden="true">×</span>
</button>

Why this works better: screen readers can announce this as a button named “Close dialog”, and keyboard users can activate it predictably.

3) Structure + labels for fast non-visual navigation

<a class="skip-link" href="#main-content">Skip to main content</a>

<main id="main-content">
  <h1>Checkout</h1>
  <form>
    <label for="email">Email address</label>
    <input id="email" name="email" type="email" autocomplete="email" />
  </form>
</main>

How screen readers use this: users can skip repeated navigation, jump to the main landmark, hear the page heading, and get the input announced with its label.