Screen Reader Testing

Screen reader testing means operating the product the way somebody using assistive technology does, and listening to what it says. It is the half of accessibility automated tools cannot reach.

A scanner confirms a label exists. Only a person hears that the label is "Field 3".

Start with the keyboard

Before any screen reader, tab through the product.

Can you reach everything? Anything operable by mouse should be reachable.

Can you see where you are? A visible focus indicator, not the one the team removed because it looked untidy.

Does focus follow the layout? Or does it jump to the footer and back because of DOM order.

Can you get out? Focus that enters a modal or a custom dropdown and cannot leave is a keyboard trap, and it is the single most blocking defect in this area.

This costs fifteen minutes and finds a surprising share of the problems.

The combinations that matter

Pair the reader with the browser it is actually used with — the combination changes behaviour.

NVDA is free, which removes the usual excuse for not starting.

What to listen for

Does each control announce what it is and what state it is in? A styled div acting as a checkbox announces neither.

Do errors interrupt? An error needs an assertive live region. A polite one queues behind other output, and somebody keeps working against a failure they have not heard.

Do headings describe the structure? Screen reader users navigate by heading far more than by scrolling. Headings chosen for size rather than level produce a document outline that makes no sense.

Is anything announced that should not be? Decorative images reading their filenames, an icon announcing "image button", a table of layout divs read as data.

Does dynamic content say anything at all? Content that appears after an action — a filter result, a saved confirmation — is frequently silent.

An hour of it changes how people design

This is the part worth arguing for internally.

Hearing a form announce "edit text, edit text, edit text" because the labels were placeholders teaches something no written guideline conveys. Designers who have spent an hour with a screen reader stop producing that form, permanently.

It is one of the highest-value hours available in the discipline, and it does not require anybody to become an expert.

Where teams get it wrong

• Skipping the keyboard pass. Fifteen minutes that finds the blockers.
• Testing with one reader and shipping. The combinations behave differently.
• Focus outlines removed for looks. A visible defect sold as polish.
• Errors in a polite region. Announced eventually, after it matters.
• Only engineers testing. The decisions that caused it were made earlier.
• Treating a clean scan as done. It is the floor.