VoiceOver
Apple's built-in screen reader, included on every macOS and iOS device. On iOS, VoiceOver is the assumed reference screen reader for mobile-web accessibility testing.
VoiceOver is Apple’s built-in screen reader, shipped on every Mac, iPhone, iPad, Apple Watch, and Apple TV at no additional cost. On iOS specifically, VoiceOver is the assumed reference screen reader for any meaningful mobile-web accessibility testing.
On macOS
VoiceOver on macOS is invoked with Cmd+F5 (or by holding the Touch ID button on supported keyboards). It has its own modifier key — the VoiceOver key (VO), typically Caps Lock or Control+Option — that prefixes most VoiceOver-specific shortcuts. Once active, VoiceOver announces the focused element, the role, and the state.
Macroscopically VoiceOver-on-macOS behaves similarly to JAWS or NVDA on Windows: keyboard navigation by landmark, by heading, by form field; ARIA role/state/value announcements; live-region handling.
Microscopically there are quirks that catch developers used to Windows testing:
- The VoiceOver “rotor” is Apple’s interaction-mode equivalent of JAWS’s virtual cursor / forms mode. VO+U opens a rotor (a stylised ring) listing navigation modes — headings, links, form controls, landmarks, web spots. Users pick a mode and arrow through items of that type.
<button>vsrole="button"— VoiceOver historically announced these differently in subtle ways; modern Safari has narrowed but not fully eliminated the gap.- Custom focus rings. VoiceOver on macOS draws its own dark outline around the focused element. If your page also draws a focus ring, both are visible simultaneously and can clash visually.
On iOS — the more important platform
On iOS, VoiceOver is invoked via the Accessibility Shortcut (triple-press the side button or via Settings). The interaction model is gesture-based and is the operative standard for mobile a11y:
- Single-finger swipe right — move focus to the next element.
- Single-finger swipe left — previous element.
- Single-finger double-tap — activate the focused element.
- Three-finger swipe up/down — scroll the screen.
- Two-finger pinch — exit and re-enter elements with sub-structure.
- VoiceOver rotor (two-finger rotation on the touchscreen) — same concept as macOS; navigate by landmarks, headings, etc.
These gestures are the de facto vocabulary for mobile screen-reader usage. Any web app or page that breaks them — by hijacking touch events, by trapping focus, by making elements undismissable — is a straightforward mobile-a11y bug.
What VoiceOver-on-iOS testing looks like
Three patterns surface most iOS-VoiceOver bugs:
- Tap through the full screen with single-finger swipes. Tab order should match visual order. Every interactive element should announce its role.
- Open the rotor and check the heading and landmark lists. Missing landmarks or skipped heading levels are immediately visible there.
- Trigger any dynamic update (carousel advance, expand/collapse,
form submit). Verify the change is announced via the appropriate
aria-liveregion, not via a silent DOM mutation the user never hears.
VoiceOver on iOS is also Apple’s reference for native iOS apps; the same testing skill set carries across web and native within the Apple ecosystem.