Testing Guide • Updated July 2026

VoiceOver Screen Reader Testing: The Complete Guide

VoiceOver is built into every Mac and iPhone, so it is the screen reader your Apple users already have. This guide takes you from turning it on to a repeatable testing workflow — the VO keys, the Rotor, iOS gestures, and full command cheat sheets for macOS and iOS — with every finding mapped to WCAG 2.2 AA.

Why Test with VoiceOver

A screen reader turns the visual interface into speech and braille. It reads out headings, links, buttons, form labels, and status messages, and lets the user navigate by those structures instead of by sight. If your markup is wrong — a button with no name, an image with no alt text, an update that never announces — the screen reader has nothing meaningful to say, and the feature is unusable no matter how good it looks.

VoiceOver is Apple’s screen reader, built into macOS, iOS, and iPadOS. There is nothing to install, which makes it the most practical way to hear how your site behaves for Mac and iPhone users — and on mobile, VoiceOver on iOS is one of the two screen readers most people use to browse on a phone. Automated scanners like axe and WAVE catch roughly a third of issues; the rest — does this actually make sense when read aloud, and can I operate it by swipe? — needs a human listening with a real screen reader. This guide is the VoiceOver-specific companion to our NVDA testing guide and our broader screen reader testing guide, which also covers JAWS and TalkBack.

1. Turn On & Configure VoiceOver

VoiceOver is already on your device — you just enable it. Set up the toggle shortcut before you start, because the interaction model changes the moment VoiceOver turns on and you want a reliable way back out.

On macOS

Press Cmd+F5 to toggle VoiceOver on and off.
Open VoiceOver Utility (VO+F8) and, under General, tick Allow Caps Lock to be used as the VoiceOver modifier for easier one-key commands.
Test in Safari, the best-supported pairing.
Press Control anytime to silence speech.

On iPhone & iPad

Go to Settings → Accessibility → Accessibility Shortcut and choose VoiceOver.
Now triple-click the side button (or Home button) to toggle VoiceOver on and off.
Test in Safari, the reference browser on iOS.
Two-finger tap pauses and resumes speech while you think.

Test on both platforms when you can. The same page can behave differently under VoiceOver on macOS versus iOS because touch and keyboard interaction differ — a custom widget that works with the VO keys may not respond to a double-tap gesture.

2. The VO Keys and the Rotor — the Two Things to Understand

Two concepts explain most of how VoiceOver works. Get these right and the rest of the commands fall into place.

The VO modifier keys

On macOS, most commands start with VO — Control+Option held together. So VO+A is Control+Option+A.

VO+→ moves to the next item
VO+Space activates the current control
VO+U opens the Rotor

Enable Caps Lock as the VO key to press a single key instead of two. On iOS there are no VO keys — you use gestures instead.

The Rotor

The Rotor jumps through a page by element type — the way a screen reader user surveys a page.

macOS: VO+U, then arrow keys
iOS: rotate two fingers, then swipe up/down
Pick Headings, Links, Landmarks, Form Controls…

Checking that Headings, Links, and Landmarks all appear correctly in the Rotor is the fastest structural audit you can run.

One more idea worth knowing on macOS: interacting. Web content, tables, and groups are containers you step into with VO+Shift+↓ and step out of with VO+Shift+↑. If VoiceOver seems stuck reading a whole region as one lump, or you cannot reach cells inside a table, you probably need to interact with it first. The cleanest way to avoid confusing behavior is to build on native, keyboard-operable elements and correct ARIA roles and states.

3. Essential VoiceOver Commands on macOS (Cheat Sheet)

VO below means the VoiceOver modifier — Control+Option, or CapsLock if you enabled it. These commands cover almost everything you need to test a web page on the Mac.

Essential VoiceOver keyboard commands on macOS and what each one does
Command	What it does
`Cmd+F5`	Turn VoiceOver on or off
`VO+A`	Read all — start reading from the current position
`Control`	Stop speech immediately
`VO+→ / VO+←`	Move to the next / previous item
`VO+Space`	Activate the current link, button, or control
`VO+U`	Open the Rotor (headings, links, landmarks, form controls)
`VO+Cmd+H`	Next heading (Shift for previous)
`VO+Cmd+L`	Next link (Shift for previous)
`VO+Cmd+J`	Next form control (Shift for previous)
`VO+Cmd+X`	Next list (Shift for previous)
`VO+Cmd+T`	Next table (Shift for previous)
`VO+Shift+↓`	Interact with (step into) a group, table, or web area
`VO+Shift+↑`	Stop interacting with the current group
`VO+F`	Find text on the page
`VO+F7`	Read the item summary / where you are
`VO+;`	Lock the VO modifier keys on or off

To learn what any key does without triggering it, turn on the VoiceOver keyboard help with VO+K and press keys freely; press Escape to leave help. The full command set lives in the built-in VoiceOver Help menu (VO+H).

4. Essential VoiceOver Gestures on iPhone & iPad

On iOS there are no keyboard commands — you drive VoiceOver with touch gestures. These are the ones you need to test a web page in Safari on a phone or tablet.

Essential VoiceOver touch gestures on iOS and what each one does
Gesture	What it does
Single tap	Select and speak the item under your finger
Swipe right / left	Move to the next / previous item
Double tap	Activate the selected item (link, button, control)
Two-finger tap	Pause or resume speech
Two-finger swipe up	Read all from the top of the screen
Two-finger swipe down	Read all from the current position
Rotate two fingers	Turn the Rotor to change navigation type
Swipe up / down (after Rotor)	Move by the chosen Rotor type (headings, links, etc.)
Three-finger swipe up / down	Scroll the page one screen
Three-finger tap	Speak extra info (page position, item count)
Two-finger scrub (Z shape)	Escape / go back / dismiss
Triple-click side button	Toggle VoiceOver (if shortcut is set)

The single most useful habit on iOS is to swipe right repeatedly through the whole page: this follows the exact reading order a VoiceOver user experiences, so anything out of order, unlabeled, or unreachable by swipe shows up immediately. Then use the Rotor (rotate two fingers) to jump by headings and links.

5. Audit Structure with the Rotor

Open the Rotor (VO+U on macOS, rotate two fingers on iOS) and step through each category. This is exactly how a screen reader user surveys an unfamiliar page, so it is the fastest structural audit you can run.

Headings. Confirm there is exactly one <h1>, that levels do not skip (an <h2> is not followed by an <h4>), and that the outline reads like a table of contents. Maps to 1.3.1 Info and Relationships.
Links. Every link should make sense on its own — no bare “click here” or “read more” repeated a dozen times (2.4.x link purpose).
Landmarks. Look for banner, navigation, main, and contentinfo so users can jump between page regions.
Form Controls. Each should announce a clear label, not “edit text.” Cross-check with the accessible forms guide.

6. A Repeatable VoiceOver Testing Workflow

Run this pass on every key page or flow. On macOS use the VO commands; on iOS use the equivalent gestures noted in brackets.

Check the page title. It should be unique and describe the page, not just the site name. VoiceOver announces it when the page loads.
Survey the structure. Open the Rotor (VO+U / rotate two fingers) and review headings, then links, then landmarks.
Read it all. Use VO+A(two-finger swipe up on iOS) to read from the top. Note anything that sounds wrong — an image reading its file name, a button that says only “button,” text in the wrong order.
Move through every item. Use VO+→ (swipe right on iOS) to walk the whole page in reading order. Every link, button, and field should announce a name and a role.
Operate each widget. Open menus, toggle disclosures, use custom selects with VO+Space (double tap on iOS). The state — expanded, selected, checked — should be spoken.
Trigger dynamic changes. Submit a form with an error, add to cart, filter a list. VoiceOver should announce the change without you moving focus — that is 4.1.3 Status Messages.
Check modals and focus. When a dialog opens, focus should move into it and stay trapped; closing should return focus to the trigger. See the focus management guide.

Common VoiceOver Findings & How to Fix Them

These are the problems VoiceOver surfaces most often. Each one is a real WCAG failure that automated tools frequently miss or can only partially detect.

Common problems found when testing with VoiceOver, why they fail, and the fix
What you hear	Why it fails	The fix
A button VoiceOver announces only as "button" with no name.	No accessible name — the user cannot tell what it does (WCAG 4.1.2).	Give it visible text, aria-label, or aria-labelledby.
An icon-only link that reads its URL or nothing at all.	Missing accessible name for the link (WCAG 2.4.4, 4.1.2).	Add visually hidden text or aria-label describing the destination.
A form field that speaks as "edit text" with no label.	Unlabeled input — the user does not know what to type (WCAG 1.3.1, 4.1.2).	Associate a <label> with for/id, or use aria-label.
A custom control you can select by swipe but not operate.	Missing role/state or no gesture support (WCAG 2.1.1, 4.1.2).	Use native elements, or add correct role, state, and key/gesture handling.
An error or cart count updates visually but VoiceOver stays silent.	Dynamic change is not announced (WCAG 4.1.3 Status Messages).	Put the update in an aria-live="polite" (or role="alert") region.
A decorative image that reads its file name into the Rotor.	Meaningless non-text content adds noise (WCAG 1.1.1).	Use empty alt="" for decoration; concise alt for meaningful images.

Fixing most of these comes down to correct roles, names, and states — the domain of the ARIA roles & attributes reference. Verify names and roles programmatically under 4.1.2 Name, Role, Value.

What VoiceOver Testing Verifies in WCAG 2.2

WCAG 2.2 success criteria you can verify by testing with VoiceOver
Criterion	Level	What VoiceOver reveals
1.1.1 Non-text Content	A	Images announce meaningful alt text, not file names.
1.3.1 Info and Relationships	A	Headings, lists, and tables convey real structure in the Rotor.
2.1.1 Keyboard	A	Every control is reachable and operable by keyboard or swipe.
2.4.3 Focus Order	A	Swiping right follows a logical, meaningful reading order.
4.1.2 Name, Role, Value	A	Controls announce an accessible name, role, and current state.
4.1.3 Status Messages	AA	Dynamic updates are announced without moving focus.

See the full picture in the WCAG 2.2 Level AA requirements and track your coverage with the WCAG 2.2 checklist.

VoiceOver vs NVDA in brief

VoiceOver is Apple-only (macOS/iOS); NVDA is Windows-only.
Both are free; VoiceOver is built in, NVDA is a download.
They interpret ARIA differently — test with both.
VoiceOver pairs best with Safari; NVDA with Firefox/Chrome.

See the NVDA testing guide for the Windows side.

Test the keyboard first

A screen reader relies on the keyboard working.
If Tab cannot reach a control, VoiceOver struggles too.
Fix keyboard operability before chasing speech bugs.

Start with the keyboard accessibility guide.

VoiceOver Testing Checklist

Setup. VoiceOver toggle set (Cmd+F5 / triple-click), testing in Safari, VO modifier configured on Mac.
Title & structure. Unique page title; one <h1>; heading levels do not skip; landmarks present in the Rotor.
Names & roles. Every link, button, and field announces a clear name and its role — no “button” or “edit text.”
Reading order. Swiping right (or VO+→) follows a logical order that matches the visual layout.
Widgets. Custom controls can be operated by swipe/double-tap and speak their state (expanded, selected, checked).
Dynamic updates. Errors, cart counts, and filter results are announced via live regions.
Dialogs. Focus moves into modals, is trapped, and returns to the trigger on close.
Both platforms. Verified on macOS and at least one iOS device, since behavior can differ.

Scan Before You Listen

Automated scanning clears the obvious issues so your VoiceOver time is spent on the problems only a human can hear. Run a free axe-core scan first, then work through the VoiceOver pass above.

Scan a Page Now Screen Reader Testing Guide

Frequently Asked Questions

Is VoiceOver free, and why test with it?▾

Yes. VoiceOver is Apple's screen reader, built into every Mac, iPhone, and iPad at no extra cost — there is nothing to download. It is the dominant screen reader on Apple platforms and, on mobile, VoiceOver on iOS is one of the two screen readers (with TalkBack on Android) that the majority of screen reader users rely on when browsing on a phone. Testing with VoiceOver reveals problems no automated scanner can catch: controls that speak as unlabeled, headings that fail to convey structure, custom widgets a user cannot operate by swipe, and dynamic updates that are never announced. If your audience includes Mac or iPhone users — and it does — you need to test with VoiceOver.

What are the VO keys in VoiceOver?▾

On macOS, most VoiceOver commands start with the VO modifier, which is Control + Option pressed together (written as VO in command lists). So a command written as VO+A means Control+Option+A. You can also turn on the VoiceOver key lock with VO+; to hold the modifier down. Many testers enable "Allow Caps Lock to be used as the VoiceOver modifier" in VoiceOver Utility so a single key acts as VO, which is far easier on laptops. On iOS there is no VO key — you drive VoiceOver entirely with touch gestures instead of key combinations.

What is the VoiceOver Rotor and how do I use it?▾

The Rotor is VoiceOver's tool for jumping through a page by element type — headings, links, form controls, landmarks, tables, and more. On macOS, press VO+U to open the Rotor, use the Left and Right arrows to choose a category such as Headings or Links, then Up and Down arrows to move between items of that type. On iOS, rotate two fingers on the screen as if turning a dial to pick a category, then swipe up or down with one finger to move through items of that type. The Rotor is exactly how a screen reader user surveys an unfamiliar page, so checking that your headings, links, and landmarks all appear correctly in the Rotor is one of the fastest structural audits you can run.

Which browser should I use to test with VoiceOver?▾

Use Safari. VoiceOver and Safari are both made by Apple and are developed and tested together, so they have the most reliable, best-supported pairing on both macOS and iOS. On the iPhone and iPad, Safari is effectively the reference browser for VoiceOver testing. On the Mac you can also spot-check in Chrome, but treat Safari + VoiceOver as the canonical combination — a bug that only appears outside Safari is worth noting, while a failure that reproduces in Safari is almost certainly a real accessibility defect.