Automated accessibility tools catch about 30% of issues. The rest require manual testing. Screen reader testing sounds intimidating if you haven't done it before — but a basic workflow catches the vast majority of problems.
The Setup
On macOS, VoiceOver is built in. Turn it on with Cmd+F5. On Windows, NVDA is free and widely used. For mobile, iOS VoiceOver and Android TalkBack are both free.
I test primarily with VoiceOver on Safari on macOS. This is the most common screen reader + browser combination among blind users on desktop. Chrome + NVDA on Windows is a close second and worth checking for anything complex.
What I Test
Reading order — turn off the display with VoiceOver's Curtain (VO+Shift+F11) and navigate the page. Does it make sense without visual context? Does the reading order match the visual order?
Form labels — tab to every input. Does VoiceOver announce the label? Does it announce the error state when validation fails?
Images — every meaningful image needs descriptive alt text. Decorative images need alt="". Icons used as buttons need an accessible name.
Dynamic content — when content updates without a page reload (modals, toasts, live regions), does VoiceOver announce it? Use aria-live for status messages.
The Shortcut
The single highest-value thing you can do is run through your critical user flows with a screen reader once per sprint. Not every component, not every page — just the flows that matter: sign up, log in, complete the core action.
Most issues cluster in these flows. Fixing them covers the majority of real-world impact.