The Screen Reader Rehearsal

---
name: Screen Reader Rehearsal
description: Produces a turn-by-turn script of how a screen reader will likely announce a page, based on NVDA + Chrome defaults.
when_to_use: A designer, PM, or dev wants to know what their page sounds like without installing assistive tech.
---

# Screen Reader Rehearsal

## What this skill does
Takes a description or markup of a page and produces a turn-by-turn announcement script: the phrases a screen-reader user would likely hear, in the order they'd hear them, as they navigate. Uses NVDA + Chrome defaults as the baseline and flags where other combinations differ.

## When to load this skill
Load when the user says any of: "what will a screen reader say", "rehearse this page", "I can't install NVDA", "walk me through how this sounds", "what do blind users hear", or pastes a page and asks for a screen-reader preview.

## The procedure

### Step 1 — Confirm the baseline
Tell the user, up front, that the rehearsal is based on NVDA 2024+ running on Chrome on Windows, with default punctuation and verbosity settings. State clearly that JAWS, VoiceOver (macOS and iOS), and TalkBack announce things differently — sometimes in meaningful ways. This is a rehearsal, not a recording. The designer should still test with real assistive tech before shipping.

### Step 2 — Extract the screen-reader-visible structure
From the pasted markup or description, extract the parts a screen reader actually navigates: landmarks (`<header>`, `<nav>`, `<main>`, `<footer>`, `role="region"`), heading hierarchy (h1–h6), links, buttons, form fields and their labels, lists, tables, images with alt text, and live regions. Ignore purely visual decoration. If the user pasted a screenshot, ask for the markup or a structural description — rehearsal from pixels alone is guessing.

### Step 3 — Build the load announcement
Every rehearsal starts with what NVDA says when the page loads: the page title, then (depending on the user's browse-mode setting) the first landmark or heading. Write it literally: `NVDA: "a-gnt signup — Mozilla Firefox. Main landmark. Heading level 1, Sign up for a-gnt."`. If the page has a skip link, it comes first. If the `<title>` is missing, say so — that's a finding.

### Step 4 — Walk the tab order
Step through the page as if the user is pressing Tab. For each stop, write what NVDA announces. Follow the documented announcement pattern: **accessible name + role + state + (sometimes) description**. A button says `"Save changes, button"`. A required email field says `"Email, edit, required, has autocomplete"`. A checked checkbox says `"Subscribe to updates, checkbox, checked"`. An error state says `"Email, edit, required, invalid entry. Enter a valid email address."`. Walk every interactive element in order.

### Step 5 — Simulate key interactions
For each interaction the user is likely to perform — filling a form, opening a menu, triggering an error, dismissing a modal — write the script. Modals: focus should move into the modal, the modal's role and name should be announced, focus should trap, Escape should close. Menus: arrow keys move between items, Enter activates. Dynamic content (search results, form errors): is there a live region? What does it announce when it updates? If there isn't one, the skill notes the silence — that's a finding.

### Step 6 — List differences and findings
Close with two short sections. **Likely differences in other AT:** "VoiceOver will announce the image alt before the role; JAWS might read the landmark name differently; TalkBack swipe navigation will not announce the skip link". **Findings surfaced by the rehearsal:** any place where the script revealed a missing label, a mute update, a focus jump, an unannounced state change, or an unhelpful reading order. Hand off to [Form Accessibility Audit](/agents/skill-form-accessibility-audit) or [WCAG Quick Audit](/agents/skill-wcag-quick-audit) if the findings need structured follow-up.

## A worked example

**User:** Rehearse this signup page. NVDA + Chrome.

```html
<title>Sign up — Acme</title>
<main>
  <h1>Create your account</h1>
  <form>
    <label for="email">Email</label>
    <input id="email" type="email" required autocomplete="email">
    <label for="pw">Password</label>
    <input id="pw" type="password" required autocomplete="new-password"
           aria-describedby="pw-help">
    <div id="pw-help">At least 8 characters.</div>
    <button type="submit">Create account</button>
  </form>
</main>
```

**Claude:** Rehearsal based on NVDA 2024 + Chrome. Real behavior may vary.

**Page load:**
> NVDA: "Sign up — Acme. Main landmark. Heading level 1, Create your account."

**Tab 1 — email field:**
> NVDA: "Email, edit, required, has autocomplete."

**User types `josephine@example.com`.**
> (No announcement per character in default browse mode.)

**Tab 2 — password field:**
> NVDA: "Password, edit, protected, required, has autocomplete. At least 8 characters."
> (The description from `aria-describedby` is spoken after the field.)

**User types a password.**

**Tab 3 — submit button:**
> NVDA: "Create account, button."

**User presses Enter.**

If the submit fails with a server error and no live region:
> NVDA: (silence)
> Finding: submit errors will not be announced. Add `role="alert"` to the error container or `aria-live="polite"` with focus moved to the first invalid field.

If the submit succeeds and the page navigates:
> NVDA: (announces the new page title, then the first landmark or heading.)

**Likely differences in other AT:**
- JAWS will read the password description slightly differently and may announce "required" before "protected".
- VoiceOver (Mac Safari) may not announce "has autocomplete" at all; it treats that as silent metadata.
- TalkBack on Android reads type="email" fields as "email, edit box" and may suppress the "required" announcement unless you use `aria-required="true"` explicitly.

**Findings surfaced by rehearsal:**
1. If form submission errors, there's no live region — the error will be silent. Blocker.
2. No skip link. For a one-form page this is acceptable, but any additional nav chrome above the `<main>` would need one.
3. The `aria-describedby` hookup works; password help will be spoken. Good.

Want me to run the full form accessibility audit on the fix for #1?

**User:** Yes, and show me what the error announcement should sound like.

**Claude:** With the fix in place — `role="alert"` on the error container, focus moved to the first invalid field — the rehearsal for a failed submit would go:

> NVDA: "Alert. Please fix 2 errors below before submitting."
> (Focus moves to the email field.)
> NVDA: "Email, edit, required, invalid entry. Enter a valid email address."
> User: Tab.
> NVDA: "Password, edit, protected, required, invalid entry. At least 8 characters."

Now the user hears what's wrong, where, and what to do. Loading the form accessibility audit for the structural fix...

## What this skill will NOT do
- Will NOT claim to represent exactly how any specific screen reader will behave. It says "likely" and names the baseline.
- Will NOT replace testing with real users on real AT. It says so in every rehearsal.
- Will NOT rehearse from screenshots alone. It asks for markup or structural description.
- Will NOT invent `aria-*` attributes into the user's code mid-rehearsal. If the code is missing something, the rehearsal shows the silence.
- Will NOT recommend overriding default screen-reader behavior (verbose-mode hacks, aria-live abuse). Defaults are the baseline for a reason.