Screen Reader Testing Checklist for WCAG

If you build web apps, screen reader testing should not happen only at the end of a project.

Many screen reader issues come from ordinary implementation choices: missing labels, incorrect roles, bad focus movement, hidden content, unannounced validation, and overused ARIA.

1. Start with semantic HTML

Before adding ARIA, check whether native HTML can solve the problem.

Review:

• Headings.
• Buttons.
• Links.
• Lists.
• Tables.
• Forms.
• Landmarks.
• Dialog structure.

Native controls usually provide better baseline semantics than custom div-based controls.

2. Check names, roles, states, and values

For every interactive control, ask:

• What is its accessible name?
• What role is exposed?
• Is its current state announced?
• Does the value update correctly?
• Does the visible label match the accessible label?

This matters for buttons, toggles, tabs, comboboxes, sliders, menus, accordions, and custom widgets.

3. Test focus movement

Screen reader testing often depends on keyboard flow.

Check:

• Focus order.
• Dialog entry and exit.
• Route changes.
• Error recovery.
• Dynamic content.
• Hidden content.
• Focus restoration after actions.

If focus moves to the wrong place, the user may not understand what changed.

4. Test forms with invalid data

Forms should be tested with real states, not only the happy path.

Check labels, instructions, required fields, input purpose, validation errors, field relationships, and confirmation messages.

Errors should be understandable and connected to the relevant fields.

5. Test announcements and live regions

Dynamic updates need careful handling.

Do not announce everything. Announce what helps the user continue the task.

Common examples:

• Search results changed.
• Item added to cart.
• File upload completed.
• Save succeeded.
• Validation failed.
• Session expired.

6. Write findings like defects

A useful finding includes:

• Assistive technology and browser used.
• Steps to reproduce.
• Expected announcement.
• Actual announcement.
• Affected component.
• User impact.
• WCAG mapping.
• Fix recommendation.
• Retest result.

This helps developers fix the behavior, not only the markup.

Conclusion

Screen reader testing is not mysterious. It is structured interaction testing with assistive technology.

Use semantic HTML, verify names and roles, test forms and dynamic updates, and document evidence clearly.

Read the original guide on IAAP Audit: https://iaapaudit.com/blog/screen-reader-testing-checklist-accessibility-audits