There is no separate mobile accessibility standard, and that is W3C's own position rather than our shortcut. WCAG applies to your site whatever it is viewed on, and several of its rules exist specifically because of phones and tablets.
What changes on mobile is which failures hurt most. A layout problem that is mildly awkward on a desktop becomes a blocker on a 375-pixel screen held one-handed on a moving bus. And there is a conformance rule that decides how seriously to take this, which is that every layout variation a page presents at different screen sizes has to conform on its own. Your phone layout is not covered by the desktop one having passed. It is a page.
The Nine Rules That Bite Hardest
- 1.3.4 Orientation, AA. Do not lock to portrait or landscape. Somebody with a wheelchair-mounted device cannot rotate it to suit you. The exception is where an orientation is genuinely essential, and the standard's own examples are a bank cheque, a piano app, slides for a projector, and virtual reality content.
- 1.4.10 Reflow, AA. No scrolling in two directions at once, at a width equivalent to 320 CSS pixels. That is a phone, and it is also a desktop at 400% zoom, because 320 pixels is what a 1280-pixel window becomes at that magnification. Content that scrolls sideways gets the same treatment at 256 pixels of height.
- 2.5.1 Pointer Gestures, A. Anything needing a path or two fingers needs an alternative that works with a single pointer and no path. That is broader than a tap, since a press and a drag where only the endpoints matter both qualify. A single-finger swipe does not, because the path is the point of it, so a swipe cannot stand in as the alternative to a pinch.
- 2.5.2 Pointer Cancellation, A. Four ways to satisfy it, not one. Do not act on the down-event, or let the action be aborted or undone, or reverse it on release, or show that the down-event is essential. Firing on release is the usual answer because it is the easiest.
- 2.5.4 Motion Actuation, A. Shake-to-undo needs a button too.
- 2.5.7 Dragging Movements, AA, new in WCAG 2.2. Anything you operate by dragging needs a single-pointer alternative that is not a drag. Sliders, reorderable lists, drag-to-upload.
- 2.5.8 Target Size, AA. 24 by 24 CSS pixels, with five exceptions, of which the one you will use is spacing. Apple asks for 44 by 44 points and Android for 48dp, and both of those are the vendors' numbers rather than WCAG's.
- 1.4.4 Resize Text, AA. Phone users set larger system text sizes, and your layout has to cope with it.
- 1.4.13 Content on Hover or Focus, AA. A tooltip that only appears on hover has no way to appear at all on a touch screen. Where it does appear, it has to be dismissable, hoverable and persistent.
The one owners are most surprised by is orientation locking, which usually got added to force a "better" experience. It is a Level AA failure, and it excludes people whose device is physically fixed in one position by the chair they are sitting in.
The Failures We Find on Mobile Sites
| What breaks | Why it happens | Who it stops |
|---|---|---|
| Pinch-zoom disabled | user-scalable=no in the viewport meta tag | Anyone with low vision, immediately |
| Tap targets too small or too close | Desktop spacing carried straight onto a phone | Anyone with a tremor or larger fingers |
| Sticky headers eating the screen | A fixed bar sized for desktop | Everyone, and worst at large text sizes |
| Carousels that only swipe | No arrow buttons added alongside the gesture | Switch and keyboard users |
| Hover-only content | Desktop tooltips ported without a tap equivalent | Every touch user |
| Fixed-height cards clipping text | System font size larger than the designer assumed | Anyone using larger text |
Disabling pinch-zoom is the one to check first, and it comes with a warning about how you check it. Safari on iOS has ignored both user-scalable=no and maximum-scale by default since iOS 10, so an iPhone will happily zoom a page that tried to stop it. Other browsers may honour the attribute or may override it depending on the user's settings, so the lockout is real somewhere and you cannot tell where from your own handset.
Which means the obvious test gives you the wrong answer. Pinch-zooming your own site on an iPhone will work, and it will work whether or not your markup is trying to prevent it. Read the markup instead. Search your codebase for user-scalable and maximum-scale and take them out, because shipping an instruction to disable zoom is indefensible whether or not one vendor is currently protecting you from it.
Mobile Web and Native Apps Are Different Jobs
Worth being precise, because the two get quoted as one thing and they are not.
| Mobile web | Native app | |
|---|---|---|
| What it is | Your website in a phone browser | An installed iOS or Android app |
| Standard | WCAG 2.2 directly | WCAG read through WCAG2ICT, and a WCAG2Mobile draft in progress |
| Built with | HTML, CSS, JavaScript | Swift, Kotlin, React Native, Flutter |
| Accessibility layer | The DOM and ARIA | Platform APIs: UIAccessibility, Android AccessibilityNodeInfo |
| Tested with | VoiceOver on iOS Safari, TalkBack on Android | VoiceOver and TalkBack against the app build |
That second row is worth reading twice, because most advice sends you to Apple and Google for the native answer. Their guidance is useful and it is not the standards route. W3C publishes WCAG2ICT, which applies WCAG to software that is not a web page, and it has a draft specifically on applying WCAG 2.2 to mobile applications in progress. If a procurement document asks which standard your app meets, those are the documents the question is about.
A responsive website tested on a phone is mobile web. Everything on this page and in our checklists applies to it directly.
What a Desktop Audit Already Told You About Your Phone Layout
Some of it transfers exactly, some of it has to be looked at again, and some of it was never in the room. Which of the three a finding falls into depends on what its rule is a property of, so the sorting is mechanical rather than a matter of opinion.
| What happens to it | Why | What it covers |
|---|---|---|
| Transfers unchanged | The defect is a fact about the markup, and the markup is one document at every width | A missing alt attribute, a field with no label, no declared page language, an invalid ARIA role, a control with no accessible name |
| Has to be checked again | The rule is about something rendered, and a narrow layout renders it differently | Contrast where the palette changes at the breakpoint, target size where the spacing does, focus order where the source order does |
| Was never in the room | The rule is about a device capability, a touch input, or a component that only exists below the breakpoint | Orientation, motion actuation, hover content where there is no hover, gestures as actually performed, and every hamburger menu, bottom sheet and swipe-only carousel |
One rule sits in a better place than owners expect. Reflow is the most mobile-shaped requirement in the standard and a desktop browser settles it outright, because 320 CSS pixels is what a 1280-pixel window becomes at 400% zoom. So if your evaluation tested reflow, it tested the rule that catches most of what a narrow screen does to a layout, and it did that without anybody picking up a phone.
Then the arithmetic, which is where this stops being a matter of degree. Every layout variation a page presents at different screen sizes has to conform before the page conforms at all. A desktop-width evaluation gives you a result for one variation and no result for the others, so a clean desktop report alongside an untested phone layout is not a conforming page. It is one variation with evidence and one without.
Which is a statement about what was covered rather than a prediction that your phone layout fails. It may well be fine. Nobody looked.
Testing on a Phone, in Fifteen Minutes
- Check the markup for
user-scalableandmaximum-scalerather than trying to pinch-zoom. The gesture test gives a false pass on iOS, which is the handset most people reach for. - Set your system font size to the largest option and reload. Look for clipped text and overlapping elements.
- Rotate the device on every key page, and make sure the page rotates with it.
- Turn on VoiceOver (iOS) or TalkBack (Android) and swipe through a page. Listen for unnamed buttons and unlabelled fields. This matters more than the desktop equivalent, because most screen reader use happens on a phone.
- Try every gesture-driven component without the gesture. Carousels, sliders, swipe-to-delete, drag-to-reorder.
- Complete your main task one-handed, with the phone in portrait.
The system-text-size test
This is the one people skip and, in our own audits, the one that finds the most. Fixed-height containers, single-line buttons and tightly packed cards all break when somebody turns their text up, and none of it shows at the default size you designed at. Ten seconds in your phone's settings, and it reframes the whole design.
One honest limit
Ours is the same limit. We evaluate at desktop widths, so the boundary on our own reports is the width we tested at rather than the hardware we tested on, and the free scan renders every page at 1366 pixels wide. Findings we raise are usually true at every width, and anything that only appears on a narrow screen sits outside what we looked at. Native iOS and Android app builds we do not test at all. If your traffic is overwhelmingly mobile, say so before you buy rather than after, and our method sets out what that scope does and does not answer.