Screen Reader Testing: A Brief Checklist for WCAG 2.2 AA Compliance
Use this checklist during design reviews, development QA, and before launch. It's not a replacement for a full accessibility audit, but it catches many of the issues that break real screen reader experiences.
This isn't about perfection. It's about making sure your product communicates clearly to people who can't rely on visual design.
1. Test With Real Screen Readers
Test at least one desktop screen reader:
- NVDA (Windows, free download)
- JAWS (Windows, paid download)
- VoiceOver (macOS, built-in)
Test at least one mobile screen reader:
- VoiceOver (iOS, built-in)
- TalkBack (Android, built-in)
Test with the default browser for each platform, such as Safari on Apple devices and Chrome on Windows or Android. This matches what most users actually experience. According to WebAIM, these are the most common screen reader and browser combinations in January 2024:
- JAWS with Chrome
- NVDA with Chrome
- VoiceOver with Safari
2. Navigate Without Looking at the Screen
Turn on the screen reader. Close your eyes or look away. Navigate using only gestures or keyboard commands. Listen for clarity, not just announcements.
If you cannot understand where you are or what to do next by listening alone, the experience is broken.
3. Check Page Structure and Reading Order
Listen for:
- Headings announced in a logical hierarchy (Heading 1, then Heading 2, then Heading 3)
- Content read in a sequence that makes sense
- Repeated elements like navigation and footers that behave consistently in every page.
- Headings are announced in a logical hierarchy (H1 → H2 → H3)
This supports WCAG requirements around meaningful sequence and structure, the criteria that makes content easier to follow for everyone.
This isn't about perfection. It's about making sure your product communicates clearly to people who can't rely on visual design.
4. Verify Interactive Elements
For every button, link, menu, tab, toggle, and accordion, listen for three things:
- A clear role (button, link, checkbox, input)
- A clear name (what the element does)
- A clear state (expanded, collapsed, selected, disabled)
If you hear "button" with no other context, that element needs a better label. Same for "link" or "edit text" with no explanation of what it's for.
5. Test Forms Thoroughly
Forms break more often than almost anything else. Listen for:
- A programmatic label for every input field
- Required fields announced as required along with an explanation for visual users before the form.
- Error messages announced when they appear next to the label.
- Focus moved to errors when validation fails.
Listen for announcements like “edit text” with no context. That’s a common failure that ends up with a confused user.
6. Confirm Focus Behavior
Focus order should match the logical flow of the page. Listen and watch for:
- Focus that moves in a predictable sequence
- Focus that's visible for keyboard users
- Focus that doesn't disappear or jump unexpectedly
- Modals that trap focus correctly while open
This aligns with WCAG requirement of focus order and focus management requirements, letting users know where they are on the page.
7. Review Images and Non-Text Content
Listen for what gets announced:
- Informative images should have meaningful alt text
- Decorative images should be skipped entirely
- Icons used to convey meaning need text alternatives
- No critical information should rely on color alone
If you hear an image file name like "IMG_4829.jpg" or an auto-generated AI description that's vague, the alt text needs work. Keep in mind that not all images require an alt, ensure only images that are relevant to the context at hand have an alt text.
8. Test Dynamic and Complex Components
Pay extra attention to anything interactive or that changes state:
- Modals announce themselves when opened
- Dropdowns and menus announce when they're expanded or collapsed
- Media players are fully operable with the screen reader
- Live content updates are announced when they change
Complex components are where many WCAG failures occur, pay extra attention to them during testing.
9. Zoom and Resize Content
Test at 200% zoom.
- Ensure reading order remains logical
- Confirm that the content remains accessible.
- Verify controls remain reachable and usable
Zooming in can reveal hidden structural issues that aren’t obvious at normal size. There are users that have to or prefer to read zoomed in.
10. Ask the Final Question
After testing, ask:
“If I couldn't see this interface at all, would I understand what this page is, what it offers, and how to complete my task?”
If the answer isn’t clearly yes, the experience needs improvement.
Final Takeaway
WCAG 2.2 AA compliance is not just about meeting criteria. It’s about ensuring your interface communicates clearly without relying on sight.
When you listen to your product the way screen reader users do, you start noticing things you missed. Vague labels. Confusing sequences. Elements that make visual sense but sound like nonsense when read aloud.
Screen reader testing turns accessibility from an abstract concern into a concrete usability practice. And when teams start listening regularly, better design decisions follow.
