Testing your website with NVDA, VoiceOver and TalkBack

Automated accessibility checkers catch perhaps a third of the problems on a page. They can tell you an image has no alt attribute; they cannot tell you the description is wrong, the menu announces nothing useful, or the checkout dead-ends after the payment step. The only way to know is to listen. The encouraging part is that screen reader testing needs no budget and no specialist training to get started: free software, half a dozen commands and a repeatable script will find real issues on your site this afternoon.

Choosing which screen reader to install

You do not need all of them. Start with the one that matches the device you already use, then add a second later.

• NVDA is free, open source and runs on Windows. It is the natural starting point for most Indian teams and pairs well with Chrome or Firefox.
• VoiceOver is built into macOS and iOS, so Mac and iPhone users already have it. Test it with Safari, which is the pairing Apple supports best.
• TalkBack is built into Android and is the right choice for testing how a mobile visitor experiences your site, given how much Indian traffic is Android.
• JAWS is a paid Windows product with a large user base in workplaces. Worth adding if you have budget and enterprise clients.

One important warning before you begin: turn your speaker volume down first. Screen readers start talking immediately and at speed. Also learn the off switch before the on switch, because the first minute is disorienting for everyone.

The handful of commands you actually need

Professional users know dozens of shortcuts. For testing your own site, this is enough.

NVDA on Windows

Start it with Ctrl+Alt+N and stop it with Insert+Q. Press Ctrl to silence speech instantly, which is the most useful key you will learn. Use Tab to move between interactive elements, H for the next heading, D for landmarks, K for links and F for form fields. Insert+F7 opens a list of headings and links on the page.

VoiceOver on Mac

Toggle it with Command+F5. Commands begin with Control+Option, usually called VO. VO with the arrow keys moves through content, VO+Space activates, and VO+U opens the rotor, which lists headings, links and landmarks. Control alone pauses speech.

TalkBack on Android

Enable it in Settings under Accessibility. Swipe right and left to move item by item, double tap to activate, and use the reading controls by swiping up or down to switch between headings, links and controls. Remember that every gesture changes while TalkBack is on, including how you get back to settings to turn it off.

A test script you can repeat

Run the same sequence every time so results are comparable. Keep your eyes on the screen at first; testing with the monitor off is a later exercise.

1. Load the home page and listen to the first 30 seconds. Do you learn what the business does, or hear a list of menu items and a graphic?
2. Open the heading list. Does it read like an outline of the page?
3. Jump to main content using a landmark or skip link. Does one exist?
4. Tab through the navigation. Are dropdown menus reachable and closable, and is the current page identified?
5. Open the link list. Count how many entries say "read more" or "click here".
6. Listen to a content page with images and check whether each description makes sense in the flow.
7. Complete your main form using only the keyboard. Are labels announced, is the required status clear, and are errors read out after a failed submission?
8. Use the search and confirm the result count is announced, not just displayed.
9. Open a modal, menu or popup. Does focus move into it, does Escape close it, and does focus return sensibly?
10. Finish a real task end to end, such as adding a product to the cart and reaching checkout, or submitting an enquiry.

Budget about 30 minutes for a first pass on one page and a little more for a full journey. Do the same journey on Android with TalkBack afterwards, since mobile layouts often behave differently.

Recording what you find so it gets fixed

Vague reports do not get actioned. For each issue, write down the page URL, the element, the screen reader and browser you used, what was announced, what you expected instead, and how serious it is.

"The Submit button on the contact page announces only 'button' in NVDA with Chrome; it should announce 'Send enquiry'" gives a developer everything they need. "Form not accessible" does not.

Rank issues by whether they block a task. Anything that prevents someone completing a purchase, submitting an enquiry or logging in is top priority. Anything that makes a page merely tedious can wait behind it. Keep the list in your issue tracker with the rest of the work, not in a separate document nobody opens.

Knowing the limits of your own testing

Be honest about what a sighted tester with a week of practice can and cannot judge. You will reliably find missing labels, unannounced changes, broken focus and confusing link text. You will not reliably judge how tolerable a page is at 400 words per minute, or which workarounds experienced users already have.

Differences between screen readers and browsers also matter: something that works in NVDA with Chrome may behave differently in VoiceOver with Safari. Test in at least two combinations before concluding that a feature is fine.

For anything customer-facing and important, involving people who use screen readers daily is worth far more than any checklist. Treat your own testing as the first filter, not the final verdict.

Making testing part of the routine

Add a short screen reader pass to your release checklist for any change to navigation, forms or checkout. Ten minutes on the changed page prevents most regressions, and the commands stop feeling strange after two or three sessions.

If you would rather have the first audit done for you, our team can run the tests and hand back a prioritised list you can work through; start at support or ask a specific question via ask an expert.

Frequently asked questions

Which browser should I pair with each screen reader?

NVDA works well with Chrome and Firefox, VoiceOver is best supported in Safari, and TalkBack pairs with Chrome on Android. Matching these pairings avoids chasing bugs that only exist in an unusual combination.

Should I test with the screen off?

Eventually, yes. It shows how much you were relying on sight. Start with the screen on so you can connect what you hear to what is there, then try one page blind.

How often should we run these tests?

Before any significant release, and once a quarter on key journeys. Any change to templates, forms or navigation deserves its own quick pass.

Can I test on a phone only?

It is better than nothing and matches how most Indian visitors browse, but desktop screen readers expose structural problems more clearly. Do both if you can.