Screen Reader Testing for Business Owners: VoiceOver and NVDA Basics
Short answer: You can test a purchase path with a screen reader by learning about ten commands. Turn on NVDA (Windows) or VoiceOver (Mac), move through the page by headings, links, and form fields, and listen for clear names, roles, and error messages. Anything announced as 'button' with no name, or 'edit' with no label, is worth fixing.
A screen reader turns what is on a page into speech (or braille). People who are blind or have low vision use one to browse, shop, and fill in forms. You do not need to become an expert to learn a lot from it. Thirty minutes with a screen reader on your own checkout will show you problems that no visual review catches.
This guide covers the minimum commands for NVDA on Windows and VoiceOver on Mac, a simple test script for a purchase path, what good and bad sound like, and the surprises that catch most first-time testers. It is not legal advice. For legal questions, including any demand letter, talk to an attorney.
Why test with a screen reader at all
Automated scans are useful, but they only detect a portion of accessibility problems. They can tell you an image has no alt text. They cannot tell you whether the alt text is meaningful, whether the order of announcements makes sense, or whether a person could actually finish a purchase.
The success criteria most relevant here are WCAG 4.1.2 Name, Role, Value, WCAG 1.3.1 Info and Relationships, and WCAG 3.3.2 Labels or Instructions. A screen reader makes failures of these obvious in seconds. For the wider picture, see the WCAG 2.1 AA checklist.
Testing yourself does not replace testing with experienced screen reader users, and it does not by itself show that a site meets any standard. Think of it as a fast, honest first look.
Set up: which tool and which browser
Use a pairing that is commonly used together and well supported:
- Windows: NVDA (free, from nvaccess.org) with Firefox or Chrome.
- Mac: VoiceOver (built in) with Safari.
- iPhone and Android: VoiceOver and TalkBack are built in as well. They are worth a later pass, since many shoppers use phones.
Use headphones or turn down the volume if you are in a shared space, and consider closing your eyes or dimming the screen for part of the test. The goal is to experience the page by sound.
The minimum commands
You can do a surprising amount with a handful of keys.
NVDA (Windows)
NVDA's modifier key is Insert (or Caps Lock, depending on setup).
| Task | Keys |
|---|---|
| Start or stop NVDA | Ctrl + Alt + N (if installed with the shortcut) |
| Stop speech | Ctrl |
| Read next or previous item | Down or Up arrow |
| Next heading | H (Shift + H for previous) |
| Next link | K |
| Next button | B |
| Next form field | F |
| Next landmark region | D |
| List all headings, links, or landmarks | Insert + F7 |
| Activate a link or button | Enter (or Space for buttons) |
NVDA's single-letter navigation works in "browse mode." When you enter a form field, NVDA switches to "focus mode" so you can type. You will usually hear a short sound when it switches.
VoiceOver (Mac)
VoiceOver's modifier is called VO, which is Control + Option by default.
| Task | Keys |
|---|---|
| Start or stop VoiceOver | Command + F5 |
| Stop speech | Control |
| Read next or previous item | VO + Right or Left arrow |
| Open the Rotor (list headings, links, form controls) | VO + U |
| Move through Rotor categories | Left or Right arrow |
| Move within a category | Up or Down arrow |
| Activate the current item | VO + Space |
The Rotor is the most useful VoiceOver tool for testing. It shows the page's headings, links, landmarks, and form controls as lists, which is close to how many screen reader users scan a page.
A simple test script for a purchase path
Run the same path in both tools if you can. Write down what you hear, not what you expect.
- Page title. When the page loads, listen to the title. It should describe the page, such as the product name or "Checkout." See WCAG 2.4.2 Page Titled.
- Headings. List the headings (NVDA: Insert + F7; VoiceOver: Rotor). Do they outline the page in a sensible order?
- Navigation and skip link. Press Tab once or twice from the top of the page. A "skip to main content" link is a good sign. See WCAG 2.4.1 Bypass Blocks.
- Product page. Find the product images and the price. Check the alt text and whether the options (size, color) are announced with labels.
- Add to cart. Activate the button. Does anything announce that the item was added, or does the page change silently?
- Cart. Can you hear each item, its quantity, and the total? Can you change a quantity or remove an item?
- Checkout form. Move through every field. Each should have a spoken label. Submit it empty and with a deliberately bad entry to hear the errors.
- Payment and confirmation. Embedded payment fields are a common trouble spot. Confirm you can reach, fill, and submit them, and that the confirmation is announced.
If you also want to confirm that everything works without a mouse, try the same path with only the Tab, Shift + Tab, Enter, and Space keys. See WCAG 2.1.1 Keyboard and WCAG 2.4.7 Focus Visible.
What good sounds like, and what bad sounds like
Screen readers announce a name, a role, and often a state. When all three are there, the experience is clear.
| Element | Good | Bad |
|---|---|---|
| Button | "Add to cart, button" | "Button" (no name) |
| Text field | "Email address, edit text, required" | "Edit text" (no label) |
| Link | "View order details, link" | "Click here, link" or "link" alone |
| Image | "Blue ceramic mug, 12 ounce, image" | "IMG_4821.jpg" or silence on a meaningful image |
| Checkbox | "Gift wrap, checkbox, not checked" | "Checkbox" with no name |
| Error | "Error: enter a valid ZIP code" | Nothing happens, or a red border you cannot hear |
A rule of thumb: if you cannot tell what a control does or what a field wants without looking at the screen, a person using a screen reader cannot either. Related guidance: WCAG 2.4.4 Link Purpose (In Context) and alt text for product images.
Common surprises
These tend to catch first-time testers.
Placeholder text is not a label
A field that shows "Email" in gray text may be announced as an unlabeled field, depending on how it is built. Placeholders also disappear once typing starts. A real label, connected to the field in code, is the reliable fix.
Visual order is not reading order
Layouts built with CSS can look right and be announced in a confusing sequence. Listen for a cart total that is read before the items, or a "Next" button that comes before the form.
Silent updates
When a cart count changes, a coupon is applied, or an error appears without the page reloading, sighted users see it. Screen reader users hear nothing unless the page announces the change. Listen after each action.
Pop-ups and modals
A dialog should move your screen reader focus into it and keep you there until it closes. A common failure is a pop-up that appears visually while the screen reader keeps reading the page behind it.
Too much noise
Decorative images announced with long filenames, repeated "link, link, link," and duplicate navigation all add up. Too much speech can be as tiring as too little.
Third-party widgets
Chat boxes, payment forms, booking tools, and review plugins are often built by others and are frequent sources of problems. You may need to raise issues with the vendor.
An overlay may not fix what you hear
Adding a widget to a site does not necessarily change how it sounds in a screen reader. If you are weighing one, read about accessibility overlays and lawsuits first.
Writing down what you find
Note the page, the step, the tool and browser, what you heard, and what you expected. Short notes with the date are enough. They help your developer reproduce the problem, and a dated record also helps you show what you checked and when. See the dated accessibility audit record guide.
If you are testing because of a demand letter, read what to do with an ADA website demand letter, and speak with an attorney about your specific situation. For background on how this area of law works, see ADA website lawsuits explained.
Where to go next
Fix the issues that stop a purchase first: unlabeled fields, unnamed buttons, silent errors, and inaccessible payment steps. Then retest the same path. If you run a WordPress site, the WordPress accessibility guide covers common platform issues, and the restaurant website guide covers menus and ordering.
To get a broader baseline before you start manual testing, run a free scan. Automated results are a starting point, not a verdict, and they work best alongside the manual checks above.
Frequently asked questions
Do I need to test with both VoiceOver and NVDA?
It is helpful but not required to start. Each tool, paired with a browser, can announce the same page a little differently, so testing with both catches more. If you can only do one, use the one that matches the devices your customers are most likely to use.
Can I rely on my own screen reader testing?
It is a good first check, but it is not the same as testing by experienced screen reader users, who navigate faster and in different ways than a beginner. Your testing will find obvious barriers, such as unlabeled fields and silent errors. It does not by itself show that a site meets any standard.
How long does it take to test a checkout?
A first pass through a basic purchase path often takes 30 to 60 minutes, mostly because you are learning the commands. A second pass is faster. Plan extra time for payment widgets and for repeating the test after fixes.
What if I cannot tell whether something is a problem?
Ask whether you could complete the task without seeing the screen: knowing what each control is, what it does, and what happened after you used it. If the answer is no, it is worth fixing or reviewing with a developer. For questions about legal risk, an attorney is the right person to ask.
Is a screen reader the only thing I need to test?
No. Keyboard-only use, text resizing, color contrast, captions on video, and zoom matter too. The screen reader is one important lens among several. The WCAG 2.1 AA checklist lays out the broader set of checks.
Related
- WCAG 2.1 AA checklist for business websites
- WCAG 4.1.2 Name, Role, Value
- WCAG 3.3.2 Labels or Instructions
- WCAG 1.1.1 Non-text Content
Proof of Access provides technical accessibility assessments. We are not a law firm and nothing on this page is legal advice. If you have received a demand letter or a lawsuit, talk to an attorney.