Implementation worksheet · 7 min read
A Screen Reader Smoke Test for an App-Builder Project
Pick the flow that matters most in the generated app (sign up and create the first record, say), turn on a screen reader you can run (VoiceOver with Command-F5 on a Mac, or the free NVDA on Windows), and walk the flow by ear. Check seven things: each screen's title says where you are, headings and landmarks let you jump to the main content, every control is announced with a role and a name that matches its visible label, every field announces its label, images are described or silent, confirmations such as 'Saved' are spoken without you hunting for them, and data tables announce their headers. It's a smoke test: it finds failures that block the flow, not everything an audit would.
Scope: the actor is a builder or reviewer with little or no screen reader experience who needs a repeatable first check before a generated app reaches real users. The starting state is a deployed preview with synthetic data, one role, and either macOS with VoiceOver or Windows with NVDA. The boundary is one flow of three to six screens. Mobile screen readers (VoiceOver on iOS, TalkBack on Android) behave differently and are outside this pass. The outcome is a pass, fail or unsure per check per screen, with what the screen reader said written down word for word.
Put it into practice
1. Learn a handful of commands first
In NVDA's browse mode: H moves to the next heading, D to the next landmark, F to the next form field, T to the next table, and NVDA+F7 opens the elements list. In VoiceOver: Command-F5 turns it on or off, VO means Control+Option (or Caps Lock), and VO-U opens the rotor, which lists things like headings and links. Practise on a site you know, so the session measures the app rather than your familiarity with the tool.
2. Check the title and language on every screen
When a screen loads, the screen reader reads its title. It should describe the screen ('Invoices - Acme Billing'), not repeat the app name on every route (2.4.2 Page Titled, A). In a single-page app, check the title also changes after client-side navigation. If the voice pronounces English as if it were another language, the page language is probably missing or wrong (3.1.1 Language of Page, A).
3. Jump by headings and landmarks
Use heading and landmark navigation. You should find a main region, navigation for the sidebar, and headings that describe each section (2.4.6 Headings and Labels, AA). Text that looks like a heading but is read as plain text means the visual structure isn't in the markup (1.3.1 Info and Relationships, A).
4. Tab through controls and compare names with labels
Every button and link should be announced with a role and a name (4.1.2 Name, Role, Value, A). Listen for icon-only buttons: a pencil icon announced as 'button' and nothing else. Where there is a visible label, the announced name should contain it (2.5.3 Label in Name, A), which also matters to voice-control users who say what they see.
5. Fill in a form by ear
Move through the form with Tab or the form-field key. Each field should announce its label and whether it is required. Submit it empty once. The error should reach you either because focus moved to an error summary or because the message is exposed as a status message (4.1.3 Status Messages, AA). If you had to look at the screen to learn what went wrong, record a fail.
6. Trigger a status message and listen
Save a record, apply a filter, or add an item. 'Saved', '12 results' or 'Item added' should be spoken while focus stays where it was. W3C's Understanding document for 4.1.3 uses messages of exactly this kind as its examples. A toast that appears on screen and says nothing through the screen reader is a fail.
7. Read one data table
Move into the main table (in NVDA's browse mode, T jumps to the next table) and move across cells. The column header should be announced as you move between columns; if you only hear values, the headers aren't marked up as headers (1.3.1 Info and Relationships, A).
8. Worked example (illustrative, synthetic data)
Flow: sign up, create a project called Test Project A, add a task, find it in the task table. Notes from a synthetic run: the sign-up title named the screen (pass); the email field announced its label and required state (pass); submitting the form empty announced nothing, although error text appeared on screen (fail, 4.1.3); on the project screen, the pencil icon was announced as 'button' with no name (fail, 4.1.2); in the task table, moving across a row announced 'Due date' with each date (pass). Two fails, each specific enough to fix in a single request.
Screen reader smoke test script
Copy this structure into your review document and record your observed result for each row.
| Check | How to do it | Pass when you hear | WCAG 2.2 reference | Result |
|---|---|---|---|---|
| Page title | Load each screen and listen to the first announcement | A title naming the screen, updated on every route | 2.4.2 Page Titled (A) | |
| Page language | Listen to the pronunciation | The correct language voice | 3.1.1 Language of Page (A) | |
| Landmarks | NVDA: D. VoiceOver: the rotor | A main region and navigation, plus any header or footer | 1.3.1 Info and Relationships (A); 2.4.1 Bypass Blocks (A) | |
| Headings | NVDA: H or NVDA+F7. VoiceOver: VO-U | Headings that describe each section, in a sensible order | 1.3.1 (A); 2.4.6 Headings and Labels (AA) | |
| Button and link names | Tab through the controls | A role and a name for every control, icon buttons included | 4.1.2 Name, Role, Value (A) | |
| Visible label in the name | Compare the announcement with the on-screen text | The announced name contains the visible label | 2.5.3 Label in Name (A) | |
| Form fields | NVDA: F, or Tab | Label, role and required state for each field | 3.3.2 Labels or Instructions (A); 4.1.2 (A) | |
| Form errors | Submit the form empty | The errors, without looking at the screen | 3.3.1 Error Identification (A); 4.1.3 (AA) | |
| Status messages | Save, filter or add an item | 'Saved' or a result count, with focus unchanged | 4.1.3 Status Messages (AA) | |
| Images and icons | Move through the content | Meaningful images described; decorative ones silent | 1.1.1 Non-text Content (A) | |
| Data table | NVDA: T, then move across cells | The column header with each cell | 1.3.1 Info and Relationships (A) | |
| Dialog | Open one dialog in the flow | The dialog role and its title | 4.1.2 Name, Role, Value (A) |
A failure worth checking
The smoke test that turns into an audit claim. A reviewer runs the script, gets eleven passes and one fail, fixes the fail and writes 'screen reader tested' in the release notes. That sentence will be read as 'accessible'. The pass covered one flow, one role, one screen reader and one browser, run by someone who learned the commands that morning; it didn't cover the other screens, mobile screen readers, or whether a daily screen reader user would find the flow efficient. Write down exactly what was covered. The counterexample in the other direction: skipping the smoke test because a full audit is planned leaves a blocking failure, such as an unnamed Save button, in place until the audit happens.
Common questions
Which screen reader should I test with?
The one you can run on the machine you have: VoiceOver is built into macOS, and NVDA is a free, open-source screen reader for Windows from NV Access. They differ in commands and in some announcements, so record which one, and which browser, produced each result. If you know which combination your users rely on, test that one.
Can an automated checker replace this?
No, though it's worth running one first because it finds some problems, like a field with no label, quickly. W3C's guidance on evaluation tools says some checks can't be automated and tools can't determine accessibility on their own. A checker can confirm an image has alt text; it can't tell you whether that text describes the image.
How often should I run it?
Before the first real users arrive, and again after any change to navigation, forms or shared components, because a regenerated component can change the markup on every screen that uses it.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.