May 7, 2026

How to Test Your Website with VoiceOver in 10 Minutes (No Coding Required)

Automated scanners catch about 30 to 40 percent of accessibility problems. The rest — the ones that actually frustrate real users and trigger ADA demand letters — only show up when a screen reader meets your site. The good news: you do not need to be a developer to listen.

Every Mac, iPhone, and iPad ships with a screen reader called VoiceOver. It is free, it is already installed, and you can be using it in about thirty seconds. This guide walks you through ten minutes of structured listening, gives you a checklist of what to listen for, and tells you exactly what to write down for your developer or designer to fix. No DevTools. No jargon. No code.

If you do not own a Mac, the same approach works with NVDA on Windows (free download from nvaccess.org) or TalkBack on Android. The keystrokes differ, but the listening framework is identical.

Why listen, when scanners are so much faster

Lighthouse, axe, WAVE, and Pa11y are valuable. Run them. They will catch missing alt text, low color contrast, missing form labels, and hundreds of other defects that are easy for a machine to detect. But there is an entire category of accessibility failure that no automated tool can catch: the user-experience failure.

A button can have a perfect aria-label and still be impossible to find. A form can have every field labeled correctly and still be unusable because the error messages disappear before they are read. A photo gallery can pass every automated test and still trap a screen-reader user inside a modal they cannot escape. These are the issues that show up in lawsuits. The plaintiff’s attorney does not run Lighthouse. The plaintiff’s attorney sits down with a screen reader and tries to complete a real task — buy a product, schedule an appointment, fill out a form — and writes down everywhere it breaks.

Ten minutes of structured listening will tell you more about your real risk than any automated report.

Before you start: get comfortable with the on-off switch

The single thing that scares non-developers away from screen-reader testing is the fear that you will turn it on and not be able to turn it off. So before you do anything else, learn the switch.

On a Mac: hold Command and press F5. That is the toggle. Press it once to turn VoiceOver on. Press it again to turn it off. If your Mac has a Touch ID button, the same shortcut still works — you can also triple-press the Touch ID button. On a brand-new MacBook with no F5 key visible, you may need to hold the Function (fn) key plus F5.

On an iPhone or iPad: triple-click the side button (or Home button on older models). It is worth setting this up in Settings -> Accessibility -> Accessibility Shortcut -> VoiceOver before you start, so the triple-click does the right thing.

On Windows with NVDA: press Insert + Q to quit, or Caps Lock + Q if you set NVDA to use Caps Lock as the modifier.

Test the toggle a few times before you start your real testing. When you can confidently turn the screen reader on and off, you are ready. Take the keyboard. Set the mouse aside.

The ten-minute test plan

Set a timer for ten minutes. Open your website in a fresh browser tab. Turn VoiceOver on (Command + F5). Now pretend you are a customer trying to do the most important thing on your site: buy something, book an appointment, request a quote, sign up for a newsletter, contact you.

You are going to perform this task using only the keyboard. The Tab key moves you forward. Shift + Tab moves you backward. The arrow keys, on a Mac with VoiceOver running, move through everything on the page when used with the VO modifier (Control + Option). For most sites, plain Tab is enough to start.

As you go, write down — on paper, in a Notes file, anywhere — every place where one of the following happens.

Test 1: Can you tell what page you are on?

When VoiceOver starts reading your page, the first thing it should announce is the page title and the main heading. If it just starts reading “menu, link, link, link, link,” your site has a heading-structure problem. Real screen-reader users skip directly to a page’s main heading using a shortcut (VO + Command + H on Mac). If your page has no clear h1, or has multiple h1s, or has its main heading buried below decorative content, real users get lost.

Write it down: “Heading structure is broken on the homepage.”

Most websites have a long navigation menu at the top of every page. A sighted user’s eye skips over it instantly. A screen-reader user has to listen to it on every page — unless your site has a “skip to main content” link as the very first focusable element.

Press Tab once on a fresh page load. Listen to what VoiceOver announces. If the first thing it says is “Skip to main content, link,” you have one. If it announces a logo or the first navigation item, you do not. Add it to your list.

Test 3: Are images described, or are they silent?

Move through your homepage with Tab and the arrow keys. Listen for VoiceOver to announce images. Decorative images should be silent or announce themselves as “decorative.” Meaningful images — product photos, team headshots, infographics — should announce a meaningful description (“White ceramic mug with the company logo,” not “IMG underscore 4382 dot JPG” or, worse, dead silence).

For every product photo, before-and-after gallery, or hero image that announces a filename or stays silent, write down: “Alt text missing or wrong on [page name].”

Test 4: Can you fill out the form?

Find your most important form — contact, booking, checkout, signup — and try to fill it out using only the keyboard. Tab into the first field. Listen for VoiceOver to announce the field label and any required-field indicator. Type something. Tab to the next field.

The two failures you will hear most often are: a field that announces nothing but “edit text” (no label), and a field that announces a placeholder (“name,” “email”) that disappears once you start typing, leaving the screen-reader user with no way to know what they are filling in.

Submit the form intentionally wrong — leave a required field empty. Listen for an error message. Did VoiceOver announce it? Or did a red border just appear silently next to the empty field? If the error did not announce, write it down: “Form errors are silent.”

If your site has a popup — newsletter modal, cookie banner, age-gate, photo lightbox — trigger it. Try to close it using only the keyboard. The Escape key should close it. Tab should move only between the elements inside the modal (it should “trap” focus, in accessibility jargon). When the modal closes, focus should return to the element that opened it.

If you press Escape and nothing happens, write it down. If you press Tab and end up reading the page behind the modal, write it down. If the modal closes but you have no idea where you are on the page, write it down.

Test 6: Can you complete one full task?

This is the most important test. Pretend you are a real customer. Try to complete one full transaction or task — add an item to the cart and check out, book an appointment, submit a contact form, schedule a call, sign up for a newsletter. Use only the keyboard. Listen, do not look.

Did you finish it? How long did it take? Where did you get stuck? What did you have to guess at? What had to be repeated? If you, the business owner, with no disability and full knowledge of how your own site is supposed to work, struggled to complete the task, your real users with disabilities are not completing it at all. They are leaving and never coming back.

That is your most important finding. Write it at the top of your list.

Turning your list into a fix plan

When the timer goes off, turn VoiceOver off (Command + F5 again). Look at your notes. Most ten-minute tests produce between five and fifteen items. They will fall into roughly three buckets.

The first bucket is content fixes. Missing alt text. Wrong heading levels. Forms with missing labels. Buttons that say “click here” instead of describing the action. These are usually fixable by anyone who can edit content in your CMS, in under an hour. You may not need a developer.

The second bucket is template fixes. A missing skip-link. A modal that does not trap focus. An error message that does not announce. These usually require editing a theme or a component. They are a developer task, but a small one — typically a few hours.

The third bucket is third-party tool fixes. A booking widget that locks out the keyboard. A live-chat bubble with no accessible name. A newsletter signup popup that hijacks focus. These require either replacing the tool, asking the vendor for a fix, or hiding the tool from screen-reader users while you find a better option. They are the hardest to fix on your own and often the highest legal risk.

Send the full list to your developer or your accessibility consultant. If you do not have either, our free five-minute accessibility audit covers the automated side, and we are working on a tool that pulls everything together for non-developers.

What you have just done is the test plaintiffs run

Plaintiff-side accessibility lawsuits start with one of two things: an automated scan flagging dozens of WCAG failures, or a human tester sitting down with a screen reader and trying to complete a task. The lawsuits that actually go somewhere — the ones with detailed factual allegations and serious settlement leverage — always include the second kind of evidence. “Plaintiff attempted to schedule an appointment on the booking page using the NVDA screen reader. After approximately fifteen minutes of attempts, plaintiff was unable to select a time slot.” That sentence, in some form, appears in dozens of demand letters every month.

What you just did, in ten minutes, is the same exercise. You now know roughly what a tester would find. You can fix it before they show up. That is the entire point of doing this yourself.

You do not need to do this every week. Doing it once a quarter — and any time you launch a new page, change a major template, or add a new third-party tool — is enough to catch the issues that matter. Many small business owners find that the first ten-minute test produces the longest list, and subsequent tests get shorter and faster.

Run it once. Get the list. Fix the easy ones today. Send the harder ones to your developer this week. Then sleep better.

We’re building a simple accessibility checker for non-developers — no DevTools, no jargon. Join our waitlist to get early access.