Open your analytics and look at the device split. For many small business sites, phones bring in a large share of visits. Yet most accessibility checks happen on a desktop, with a mouse nearby and a big screen. The phone version of your site, with its hamburger menu, sticky bars and tiny icons, often gets tested last or not at all.
Mobile accessibility testing does not need a device lab. One phone, ideally two (an iPhone and an Android), and some unhurried time on each key page will show you most of what matters. Here is how to test website accessibility on a phone, one check at a time.
Why mobile accessibility testing needs a real phone
Shrinking a desktop browser or using its device mode is a fine first look at layout. It is not the same as a phone. A real device has a touch screen instead of a pointer, an on-screen keyboard that covers half the page, browser bars that appear and disappear, system text and zoom settings, and a built-in screen reader that behaves differently from desktop ones. Many problems only appear when all of that is present at once.
Use Safari on the iPhone and Chrome on Android, the default browsers that VoiceOver and TalkBack are usually paired with. Clear any saved logins first, so you see the site the way a new visitor does.
Check 1: pinch to zoom, then enlarge the text
Open the page and pinch outward. The page should zoom. If it refuses, the site is probably telling the browser to block zoom in its viewport settings, which shuts out people with low vision who rely on it. Some browsers now ignore that instruction, but not all do, so treat a blocked zoom as a defect.
Next, use the browser’s own text size or page zoom setting to make text larger, then scroll through the page. Watch for text that gets cut off, buttons whose labels overflow, and headings that overlap images. WCAG’s rules on resizing text and reflow are the basis for this; our article on reflow and resizing text to 200 percent covers the detail and the desktop side of the test.
Check 2: turn the phone sideways
Rotate the phone to horizontal. The site should adapt and stay usable. WCAG includes a criterion saying content should not be locked to one orientation unless that orientation is essential, and some people have their phone mounted on a wheelchair or a stand in a fixed position.
Horizontal view is also where sticky elements cause the most damage. A fixed header, a cookie bar and a chat bubble that take a reasonable share of a tall screen can leave a strip of content a few lines high when the phone is turned. If you can barely read anything between the bars, a real visitor cannot either.
Check 3: touch targets you can actually hit
Tap your way through the page with one thumb. Pay attention to small icons and tightly packed links: social icons in the footer, pagination numbers, the close button on a popup, slider dots, the cart icon, links stacked in a sidebar.
WCAG 2.2 added 2.5.8 Target Size (Minimum), under which a target should measure 24 by 24 CSS pixels or more, with an allowance for smaller ones that have enough space around them that a mistap does not hit a neighbor. You do not need to measure everything. If you keep hitting the wrong thing, or need two attempts to close a popup, note it. Our post on touch target size explains the rule and its exceptions.
While you are tapping, try anything that relies on swiping or dragging, such as a range slider or a before-and-after image comparison. There should be a simple tap alternative, which is what 2.5.7 Dragging Movements is about.
Check 4: the mobile menu
The menu fails on phones more often than almost anything else, because it is often a different piece of code from the desktop menu. Test it separately:
- Is the menu button large enough and clearly a button?
- Does it open with a single tap, and is there an obvious way to close it?
- Can you open submenus without the whole menu closing?
- When the menu is open, is the page behind it blocked, or can you still scroll and tap things underneath?
- With a screen reader on (check 5), does the button have a name such as “Menu”, and does it say whether the menu is expanded or collapsed?
If the menu or other parts of the layout are simply broken on phones, that is a display bug as much as an accessibility one, and our guide to fixing WordPress mobile display problems is a better starting point.
Check 5: a short screen reader pass on the phone
On an iPhone, VoiceOver is in Settings, under Accessibility. Before turning it on, configure the Accessibility Shortcut in the same area, which lets you toggle VoiceOver by pressing the side button (or Home button on older models) three times. With VoiceOver on, touching the screen reads what is under your finger, swiping right or left moves to the next or previous item, and a double-tap activates the selected item. Our post on VoiceOver website testing goes further, including the rotor.
On Android, TalkBack is in the phone’s accessibility settings. It works on a similar idea of exploring by touch, swiping between items and double-tapping to activate, but menus and extra gestures vary between Android versions and phone makers, so spend a few minutes in its built-in tutorial first and make sure you know how to turn it off.
For a first pass, swipe through the top of the page and the main task, and listen for:
- Icon buttons announced as just “button” or as a file name
- Images described as “image” with nothing else
- A menu that opens visually while swipes keep reading the page behind
- Popups and cookie banners that cannot be reached, or that are only reached at the very end
- Form errors that appear on screen but are never spoken
Check 6: things that cover the screen
Phones have little room, and sites fill it with floating extras: sticky “call now” bars, chat and WhatsApp buttons, back-to-top arrows, cookie notices, newsletter slide-ins. Scroll the whole page and check whether anything important is permanently covered, such as the submit button on a form or the last lines of text above a fixed bar.
Pairing a Bluetooth keyboard with the phone adds one more check. Tab down the page and watch whether the highlighted item ever disappears under a fixed bar; a focused element hidden that way fails 2.4.11 Focus Not Obscured (Minimum). It is optional, and it catches things a finger never will.
Check 7: forms with the on-screen keyboard
Fill in your contact or booking form with your thumbs. Notice whether each field shows the right keyboard (numbers for a phone field, an email layout for email), whether labels stay visible once you start typing, and whether autofill offers your name and address. Submit it with a mistake. Can you see the error without the keyboard hiding it, and does it tell you what to change?
A form that cannot be finished on a phone loses the visitor at the very last step, so a failure here usually deserves a high severity in your notes.
Writing it up
For every issue, record the page, the phone model and operating system version, the browser, whether a screen reader was on, and what you did and saw. Screenshots matter more in mobile accessibility testing than anywhere else, because a layout problem on a small screen is hard to describe in words. Keep the list next to your desktop findings. The phone pass is one part of a complete accessibility testing method that also covers the keyboard, desktop screen readers and content, and our accessibility services for US businesses show where testing leads next.
Frequently asked questions
Can I test mobile accessibility with my browser’s device mode instead of a phone?
It is useful for a first look at layout at narrow widths, but it does not reproduce touch input, the on-screen keyboard, real zoom behavior or a mobile screen reader. Use device mode early, then confirm the important pages on at least one real iPhone and, if you can, an Android phone.
Do I need to test on both iPhone and Android?
Ideally, yes. VoiceOver and TalkBack behave differently, and Safari and Chrome render some components differently. If you only have one phone, test with what you have and borrow the other kind for your most important pages, such as the contact form, booking flow or checkout.
What is the most common mobile accessibility problem on WordPress sites?
The mobile menu. The toggle button often has no accessible name, does not report whether it is open, or lets screen reader users swipe into the page behind it. Close behind are small, crowded tap targets and sticky bars or chat buttons that cover content and form buttons.
Is turning the phone sideways really an accessibility issue?
It can be. Some people use phones or tablets fixed in one position, for example mounted on a wheelchair, and cannot rotate them. A site that only works upright, or becomes unusable sideways because sticky bars fill the screen, creates a real barrier for them.
Phone checks are among the most revealing tests you can run yourself. If you would like them done on a range of devices with screen readers and written up for your developer, our manual accessibility testing includes a dedicated mobile pass.
