screen-reader-testinglisted

# Screen reader testing Automated accessibility checkers catch maybe a third of issues; the rest (does it announce sensibly, does the flow make sense, do updates get spoken) require using an actual screen reader. Testing with one is the only way to know what a blind user actually experiences, and it routinely surprises sighted developers. ## Method 1. **Test with the real tools users use.** NVDA (free, Windows, most common), VoiceOver (built into macOS/iOS), JAWS (widespread in enterprise), TalkBack (Android): test with at least NVDA or VoiceOver, ideally the ones your users use. Screen readers differ in behavior, so what works in one can fail in another; the common ones cover most users. 2. **Learn the basic navigation, then use it.** How to move by element, by heading, by landmark, by link, by form control (each screen reader has these modes): because users navigate by structure, jumping between headings and landmarks, not reading top to bottom. Testing this way reveals whether your heading hierarchy and landmarks (see docs-information-architecture's structure, aria- usage) actually help navigation. 3. **Verify announcements make sense.** Tab through and listen: is each control announced with its name, role, and state ("Save, button", "Email, edit, required")? Do buttons say what they do, do form fields announce their labels and errors (see accessible-forms), do images have meaningful or empty alt as appropriate (see