Test without overclaiming

Prepare a representative test

Select a supported device, operating system, browser or app, screen reader, and input method. Use a realistic user journey with a clear starting point and outcome. Learn the commands required for that journey before interpreting unexpected behaviour.

• Reset the product to a known state.
• Record versions and relevant screen reader settings.
• Use real content and realistic validation conditions.
• Test the complete task rather than isolated announcements.
• Repeat unexpected results before reporting them.

What teams can test

Trained team members can evaluate whether the product exposes necessary information and supports required operations in a defined combination. This is compatibility evidence, not a complete statement about usability for all screen reader users.

• Whether every required control can be reached and operated.
• Whether names, roles, states, values, and relationships are meaningful.
• Whether structure supports efficient navigation.
• Whether focus moves predictably and context is preserved.
• Whether important dynamic changes and errors are communicated.
• Whether the core task can be completed and reversed where necessary.

What teams should not conclude

Internal testing cannot establish how efficient, learnable, or natural a flow is for experienced users. It also cannot represent the diversity of screen reader skills, settings, devices, languages, disabilities, and personal strategies.

• Do not claim that one working combination proves all supported combinations.
• Do not claim that automated checks prove screen reader usability.
• Do not treat exact announcement wording as the only acceptable result.
• Do not infer regular-user preferences from occasional team use.
• Do not replace research with experienced users when the decision requires usability evidence.

Compatibility, exploration, and user research

Compatibility testing checks defined requirements in known combinations. Exploratory testing follows unexpected behaviour and searches for risks outside scripted cases. Research with experienced users examines strategies, efficiency, expectations, workarounds, and real-world impact. These activities answer different questions and strengthen each other.

A checkout test example

Consider a checkout that includes delivery details, a payment method, validation, and confirmation. A compatibility test can verify that fields have labels, requirements are exposed, errors are connected to fields, focus reaches the error summary, payment controls are operable, and confirmation is announced. Exploratory testing can vary validation timing, return from an external payment step, refresh the page, or interrupt the task. Research with experienced users can show whether the flow is efficient, whether instructions arrive at the correct time, and whether the recovery model matches their expectations.

• The compatibility result describes the tested combination and task.
• The exploratory result identifies risks and unexpected state transitions.
• The research result describes user strategies and observed impact.
• Together, the evidence supports a stronger decision than any one activity alone.

Record enough context

A useful report lets another person reproduce the result without seeing the original screen. Document the device, operating system, browser or app, screen reader and version, starting state, exact commands, expected result, actual result, and impact on the user's task.

• Quote the relevant output when it helps explain missing or incorrect information.
• Describe focus movement separately from spoken output.
• Include a reduced example when a custom component is involved.
• State whether the issue blocks, delays, confuses, or inconveniences the user.
• Avoid vague summaries such as “does not work with screen readers.”

Prioritise by user impact

Severity depends on the task, available alternatives, frequency, affected environments, and consequences. An unlabeled control that blocks payment is different from repetitive text that slows navigation. Both can require correction, but the evidence should explain their different impact.

Test failures and interruptions

Successful paths do not contain all of the important accessibility behaviour. Disconnect the network, submit incomplete information, trigger a timeout, cancel an overlay, and return from an external step. Confirm that the product preserves context, communicates the problem, and provides an operable recovery route. Include these states in regression coverage when they have blocked or confused users before.