How do you test a page with a screen reader — what is your process?

The right screen reader / browser pairing matters: screen readers interact with the browser's accessibility API, and different browsers expose different information. Use:

• NVDA + Chrome or Firefox (Windows): NVDA is free, widely used, and represents a large portion of real screen reader users.
• JAWS + Chrome or Edge (Windows): most common in enterprise and government contexts.
• VoiceOver + Safari (macOS and iOS): Apple's screen reader, essential for iOS testing.
• TalkBack + Chrome (Android): the dominant Android screen reader.

What to verify during a screen reader walkthrough:

1. Reading order: does the logical reading order match the visual order? Arrow through the content and check.
2. Element announcements: interactive elements should announce their role and name. A "Buy now" button should be announced as "Buy now, button" not just "button".
3. State announcements: checkboxes announce "checked" or "unchecked". Accordions announce "expanded" or "collapsed". If state changes silently, users don't know what happened.
4. Form labelling: Tab to each input. It should announce the field label and type ("Email address, edit text").
5. Error messages: submit an invalid form. The error should be announced — either because the focus moves to it, or it's in a live region.
6. Images: non-decorative images should have meaningful alt text announced. Decorative images should be silent (alt="").

The most common failure is that something looks correct visually but is announced incorrectly or not at all. Running through a page with a screen reader for the first time almost always surfaces multiple issues that automated tools miss.