Screen reader accessibility testing should show whether someone can understand a page, operate its controls, and finish a task using the information the interface exposes. Hearing a page title or reaching a submit button is a useful observation, but it does not answer those three questions. A practical review needs a defined environment, realistic tasks, and a record of what happened before and after each interaction.
This guide provides a repeatable workflow for a fictional appointment service. Use it alongside the manual and automated testing plan and the keyboard testing checklist, then adapt the tasks to the service you are evaluating.
Choose the screen reader and browser combinations deliberately
Write down the operating system, browser, screen reader, and their versions before testing. Include relevant settings, the account role, the page language, and any extension that affects interaction. This makes a result reproducible and prevents two reviewers from unknowingly comparing different conditions.
Choose combinations that reflect the intended audience and the product's support commitments. A desktop review does not cover touch navigation on a phone. If mobile use is included, plan a separate review of the gestures and reading behavior available in that environment.
The ARIA Authoring Practices guidance on browser and assistive technology support recommends testing implementations with relevant combinations. Its examples illustrate patterns; copying an example does not establish that your implementation works in the environments you support.
Learn the navigation modes before judging the interface
Screen readers offer ways to read content and ways to interact directly with controls. The keys and mode names differ between products. Consult the documentation for the screen reader being used instead of transferring commands from another tool.
For example, the NVDA user guide describes browse mode for reading documents and focus mode for interacting with controls. A key can navigate the document in one mode and act on a field in another. Record the mode when a surprising result depends on it.
Practice the task on a familiar, working interface first if you are learning the tool. During evaluation, separate uncertainty about a command from a reproducible interface barrier. Retest an uncertain observation with an experienced reviewer before assigning a cause or a WCAG failure.
Review the page structure before completing a task
Start at the page entry point. Read the title and introductory content, inspect the available headings and regions, and locate the main task. Then compare that structure with the information a person needs to understand where they are and what they can do.
WAI's headings tutorial explains how headings organize content. Its page regions tutorial describes structural regions that support navigation. Use those resources to review meaning and relationships, rather than imposing a particular visual heading size as a semantic rule.
For the appointment example, check whether the service name, appointment search, results, and booking instructions can be found without reading every navigation link. Record missing or misleading structure with its effect: “The results section cannot be located through heading navigation” is more actionable than “The headings look wrong.”
Inspect names, roles, and states through real interaction
Visit the controls needed for the task. Determine whether their exposed information explains their purpose, type, and current state. Then activate them and check whether the information remains accurate after the state changes.
Understanding Name, Role, Value explains the programmatic information required for interface components. For a disclosure control, a useful review includes its name, the exposed expanded or collapsed state, and whether the revealed content can be reached. A correct state in the initial markup does not settle the state after activation.
Use this illustrative task matrix to organize observations:
| Task | Action to perform | Observation to record |
|---|---|---|
| Find an appointment | Locate search, enter a location, submit | Purpose of the search field and route to results |
| Refine the results | Open filters and choose a date | Control names, selection state, and updated results |
| Book a time | Choose an appointment and open the booking panel | Panel identity, available instructions, and usable controls |
| Correct incomplete details | Submit with required information missing | Error information, field association, and route to correction |
| Finish the booking | Correct details and submit again | Perceivable completion and access to the confirmation |
Keep the steps concrete. A reviewer should be able to reproduce the same state using the same test data. The form testing guide provides more detail for the validation and recovery branch.
Check updates without announcing every change
Pay attention when the interface changes while focus stays in place. Search results, saved settings, progress, and errors can introduce information that a user needs to know without navigating away from the current control.
Understanding Status Messages explains when qualifying status messages must be available to assistive technology without receiving focus. This does not mean that every changed element needs a live region or that all messages should interrupt speech.
Test the actual timing. Start the action, listen for the result, and repeat after another action. Record whether the message was absent, repeated excessively, interrupted relevant instructions, or described a stale state. If a developer changes an announcement, retest both the initial action and a subsequent update instead of checking the attribute alone.
Write a finding that another reviewer can reproduce
Consider this fictional finding: after applying a date filter, the results change visually, but the tested screen reader provides no result message. The reviewer can eventually discover the updated list by navigating to it. Record that sequence and investigate whether the changed information is a qualifying status message before mapping the finding to a requirement.
Include the environment, task, starting state, commands, observed output, expected information, and effect on the task. A short speech transcript can help explain an announcement issue. A screenshot can show the visual state, but cannot establish what the screen reader announced.
Avoid using an exact spoken phrase as the acceptance condition unless that phrase carries necessary meaning. Screen readers may present equivalent information differently. The retest should determine whether the required information and operation are available, with the tested environment clearly stated.
Combine expert review with user involvement and release checks
Testing with a screen reader is a method within an evaluation. It does not cover contrast, every keyboard interaction, or every disabled person's experience. WAI's guidance on involving users explains how user involvement complements standards evaluation and why results from a few participants should not be generalized to everyone.
Invite relevant users to attempt realistic tasks where the project can support that work. Record usability observations alongside technical findings, and distinguish the evidence each provides. An experienced user overcoming a difficult interaction does not remove the need to investigate the barrier.
Deliver the environment record and task matrix with the accessibility evidence handoff. When a release changes the tested component, use the regression testing guide to decide which tasks to repeat. Saved markup can support investigation, while current screen reader behavior needs a current interaction test.
Sources and the limits of this guide
The primary sources linked above were checked on 6 October 2026. WCAG defines the requirements; WAI tutorials, the ARIA Authoring Practices Guide, and the NVDA documentation explain structure, implementation, or tool operation. The appointment task matrix and finding example are OnChange's practical suggestions, not a mandatory WCAG test script or a claim about a real customer.