Maybe you work on a Mac, your phone is an iPhone, and someone has told you that “real” accessibility testing means listening to your site with a screen reader. You already own one. VoiceOver ships with every Mac and iPhone, and an hour of VoiceOver website testing will show you things no scanner can.
The first ten minutes feel strange, though. The voice talks over you, focus jumps somewhere you did not expect, and it is easy to give up. This post is about getting past that stage quickly, so you hear your pages the way a blind visitor using Apple devices hears them.
Why listen to a page that already passed a scan
An automated checker reads the code and flags patterns: an image with no alt attribute, a form field with no label, text below a contrast ratio. It cannot tell you whether the alt text makes sense, whether the reading order matches the visual order, or whether a menu that opens on screen is actually reachable by a screen reader user. Those are exactly the problems VoiceOver exposes, because it simply reads out what the browser hands it.
Apple users matter here for a plain reason. Many people who use a screen reader on a phone use an iPhone, and VoiceOver pairs with Safari, which renders some things differently from Chrome. A page that behaves with NVDA on Windows can still trip up VoiceOver, so if you only test one, you only know half the story. If you also work on Windows, our walkthrough of testing with NVDA covers the other side.
Before you start: three small preparations
- Use Safari. VoiceOver is built and tuned around Safari on both the Mac and the iPhone. Testing it in another browser tells you more about that browser than about your site.
- Know how to stop it. On a Mac, Command+F5 turns VoiceOver on and off. On an iPhone, set up the Accessibility Shortcut in Settings, under Accessibility, so a triple-click of the side or Home button toggles it. Do this first. An iPhone with VoiceOver on and no way out is a stressful five minutes.
- Slow the voice down a little. The default speech rate is fine for experienced users and too fast for someone learning. You can raise it again later.
Pick three or four pages to test rather than the whole site: the home page, one ordinary content page, the contact page with its form, and whatever page earns you money (a booking page, a product page, a donation form). Templates repeat, so the same problem usually appears everywhere a template is used.
VoiceOver website testing on a Mac: the moves you actually need
VoiceOver commands use the “VO” keys, which are Control+Option held together. You do not need to memorize dozens of commands. For a first pass, these are enough:
- VO+Right Arrow and VO+Left Arrow move to the next and previous item, one at a time. This is the slow, honest way to hear everything in order.
- VO+Space activates the item VoiceOver is on, like a click.
- Tab and Shift+Tab still move between links, buttons and form fields, and VoiceOver announces each one as it gets focus.
- Control on its own stops the current speech, which you will want often.
- VO+U opens the rotor, covered below.
Start at the top of the page and move item by item through the header. Listen for the logo: does it say the business name and “link”, or a file name? Then the menu: does each item have a sensible name, and does VoiceOver tell you when a submenu exists and whether it is collapsed or expanded? A dropdown that only opens on mouse hover often goes silent here, which our guide to accessible dropdown menus explains in more detail.
Keep going into the main content. You are listening for order and meaning. If a sidebar block is read before the main heading, or a hero banner’s text is read twice, the visual layout and the code order have drifted apart.
The rotor: a structural check in about a minute
Press VO+U and the rotor appears: a list of everything on the page grouped by type. Left and Right Arrow switch between lists such as Headings, Links, Form Controls and Landmarks. Up and Down Arrow move through the items, and Enter takes you to the one you pick.
This is the fastest structural review there is, because it shows you what a screen reader user uses to skim.
- Headings list: is there one main heading that describes the page? Do the levels make sense, or do you see a heading 4 under a heading 2 with nothing between? Is visibly bold “heading” text missing from the list because it was styled, not marked up?
- Links list: read it out of context. “Read more, read more, read more, learn more” tells the user nothing. Duplicate links with different destinations are confusing too.
- Form controls list: every field should have a name you could act on. “Edit text” with nothing else means the label is not connected.
- Landmarks list: you should find a banner, navigation, main and content info region. Missing main content is common in older themes and page-builder layouts.
On iPhone: swiping through like a visitor would
Turn VoiceOver on in Settings, under Accessibility, then VoiceOver, or with the shortcut you set up. The touch model changes completely, which is the part people find odd:
- Touching the screen selects and reads whatever is under your finger. It does not activate it.
- A double-tap anywhere activates the selected item.
- Swiping right moves to the next item and swiping left to the previous one. This linear order is how many VoiceOver users read a page from top to bottom.
- The rotor here is a two-finger rotate, like turning a dial. Choose Headings or Links, then swipe up or down to jump by that unit.
Open your site in Safari and swipe through the header. Phones bring their own trouble. The menu toggle is often an icon with no text, announced as just “button”. When you open the menu, does focus go into it, or do your swipes keep reading the page behind it? When you close it, do you land somewhere sensible? A cookie banner or chat bubble placed at the very end of the code may only be reached after swiping through the entire page, even though it covers the screen from the start.
Then try the form. Double-tap a field, type with the on-screen keyboard, submit it empty on purpose. A sighted user sees red text appear. A VoiceOver user should hear something too. If the phone stays silent, that is a real barrier, and it fails 4.1.3 Status Messages or the error identification rules depending on how the error was built. For phone checks beyond the screen reader, see our post on testing accessibility on a phone.
What VoiceOver usually turns up on WordPress sites
Buttons with no name
Search icons, cart icons, social icons, hamburger toggles and slider arrows built from an icon font or an SVG with no text. VoiceOver says “button” and nothing more. This fails 4.1.2 Name, Role, Value and is usually a quick fix in the theme or a widget setting.
Alt text that reads like a file system
“DSC 0042 jpg, image” or the same keyword phrase on every picture. Your ears catch this instantly where your eyes never would. The fix is editorial rather than technical; see where WordPress keeps alt text for each image in the media library.
Hidden content that is not hidden
Tabs, accordions and off-screen menus that are visually collapsed but still read aloud, so the user hears every panel at once. The opposite happens too: content that appears on click but is never announced.
Popups that let you wander off
A newsletter popup opens, and swiping right goes straight past it into the page underneath. The visitor may not even know a dialog is open.
Things that keep moving
Auto-rotating sliders can make VoiceOver re-announce a new slide while the user is trying to read, or move focus away from them.
Writing down what you heard
The point of VoiceOver website testing is a finding someone else can reproduce. For each issue, note the page URL, the device and browser (for example, iPhone with Safari, or Mac with Safari), what you did, what VoiceOver said, and what you expected it to say. Quote the speech exactly. “Says ‘button’ with no name on the cart icon in the header” is something a developer can find and fix. “Menu is weird with VoiceOver” is not.
VoiceOver is one pass in a larger method. Our guide on how to test website accessibility puts it in order alongside the automated scan, the keyboard pass and the zoom checks, and our website accessibility hub gathers the related guides in one place.
Frequently asked questions
Can I test a website with VoiceOver without owning a Mac?
Yes, as long as you have some Apple device. VoiceOver is built into macOS and iOS, so an iPhone or iPad works as well as a Mac. Windows and Android have their own screen readers, NVDA and TalkBack, and testing with those is worth doing too because each one behaves a little differently.
Should I test on an iPad as well as an iPhone?
For a first pass, usually not. VoiceOver works the same way on both, with the same gestures and rotor. What can differ is the layout your theme serves at tablet width, for example a full menu instead of a hamburger toggle. If many visitors use tablets, give the menu and main form a quick listen at that width.
Which browser should I use with VoiceOver?
Safari on both the Mac and the iPhone. That is the pairing most VoiceOver users rely on, and it is the one Apple builds VoiceOver around. Results in other browsers can differ, so a bug you hear only in another browser may not affect real users the same way.
Why does VoiceOver read my page in a different order from what I see?
It follows the order of the code, not the visual layout. Page builders and CSS can place blocks anywhere on screen while the underlying order stays different. When the two drift apart, the reading order stops making sense, and the fix is usually in the layout structure rather than in the content.
Listening to your own pages is worth doing even if you never hire anyone. When you want a second pair of ears, our manual accessibility testing runs VoiceOver, NVDA and keyboard passes on your key pages and writes up each barrier with steps to reproduce it.
Next in this series: Keyboard Accessibility Testing: A Tab-by-Tab Method
