guidelines
Tap targets and touch.
Thumbs are not mouse pointers. Tap targets, zoom, gestures and the edges of a phone screen. 11 guidelines.
| Guideline | Priority | WCAG 2.2 |
|---|---|---|
| Touch targets are at least 44x44 CSS px | Critical | 2.5.8 |
| Keep at least 8px between adjacent touch targets | High | 2.5.8 |
| Put primary mobile actions in the thumb zone | Medium | - |
| Never disable pinch zoom | Critical | 1.4.4 |
| Use dvh, not vh, for full-height mobile layouts | High | - |
| Nothing may be reachable only by hover | High | - |
| Set touch-action: manipulation on tappable controls | Low | - |
| Pad fixed edges with safe-area insets | Medium | - |
| Every gesture has a single-tap alternative | High | 2.5.1 |
| Drag-and-drop always ships with a non-drag fallback | High | 2.5.7 |
| Contain scrolling inside drawers, sheets and modals | Low | - |
Critical priority
Touch targets are at least 44x44 CSS px
WCAG 2.2 success criterion 2.5.8.
Do
Give every tappable control a 44px minimum hit area (WCAG's floor is 24px; 44-48px is the comfortable standard) - pad the hit area, not necessarily the icon
Avoid
Ship a 16px close icon with zero padding in a dismissible banner - the single most rage-tap-inducing miss on mobile
On the Health Report
The report checks this: tap targets are at least 24 px. The report flags anything under 24 px, the WCAG 2.2 minimum. The guideline's 44 px is the comfortable size to aim for.
High priority
Keep at least 8px between adjacent touch targets
WCAG 2.2 success criterion 2.5.8.
Do
Separate row actions (edit/delete) and stacked links with 8px+ gaps so a thumb cannot hit 'Delete' while aiming for 'Edit'
Avoid
Butt a destructive icon directly against a routine one at identical size with zero gap
Medium priority
Put primary mobile actions in the thumb zone
Good practice, no WCAG criterion.
Do
Anchor the primary CTA and main nav to the bottom third of the screen where one-handed thumbs rest; the top corners are the hardest reach on tall phones
Avoid
Hide the only 'Continue' button in the top-right corner of a 6.7-inch screen
Critical priority
Never disable pinch zoom
WCAG 2.2 success criterion 1.4.4.
Do
Ship <meta name="viewport" content="width=device-width, initial-scale=1"> and nothing more - low-vision users depend on pinch zoom to read anything at all
Avoid
Add user-scalable=no or maximum-scale=1 to 'protect the layout' - it is a hard accessibility blocker, and browsers increasingly ignore it anyway
On the Health Report
The report checks this: pinch zoom works.
High priority
Use dvh, not vh, for full-height mobile layouts
Good practice, no WCAG criterion.
Do
min-height: 100dvh tracks the visible viewport as mobile browser bars collapse and expand, so bottom CTAs stay on screen
Avoid
Use height: 100vh and let the browser chrome hide the bottom 60-100px - the exact strip where your primary button sits
High priority
Nothing may be reachable only by hover
Good practice, no WCAG criterion.
Do
Every hover-revealed action must also appear on tap or focus; gate hover-only affordances behind @media (hover: hover) and show them persistently on coarse pointers
Avoid
Reveal a row's edit and delete buttons on mouseover only - on every touchscreen those actions simply do not exist
Low priority
Set touch-action: manipulation on tappable controls
Good practice, no WCAG criterion.
Do
Apply it to buttons and links to remove the double-tap-to-zoom delay and stop accidental zooms during rapid taps (counters, quantity steppers)
Avoid
Leave a plus/minus stepper with default touch-action so fast tapping triggers double-tap zoom instead of the second increment
Medium priority
Pad fixed edges with safe-area insets
Good practice, no WCAG criterion.
Do
With viewport-fit=cover, add env(safe-area-inset-*) padding to fixed headers and footers so notches, punch-holes and the home-indicator bar never cover controls
Avoid
Pin a bottom action bar at exactly 0 and let the home indicator sit on top of your Submit button
High priority
Every gesture has a single-tap alternative
WCAG 2.2 success criterion 2.5.1.
Do
Swipe-to-delete, pinch and two-finger gestures are accelerators, not the only path: pair swipe-delete with a visible or overflow-menu Delete button
Avoid
Make swipe the sole way to remove an item - motor-impaired users, switch users and half of first-time users will never discover it
High priority
Drag-and-drop always ships with a non-drag fallback
WCAG 2.2 success criterion 2.5.7.
Do
Reordering and kanban moves also work through 'Move up/down' buttons or a position menu - precise dragging is hard on touch and impossible for many motor impairments
Avoid
Build a sortable list where long-press-drag is the only reordering mechanism
Low priority
Contain scrolling inside drawers, sheets and modals
Good practice, no WCAG criterion.
Do
Set overscroll-behavior: contain on inner scroll areas so reaching the end does not scroll the page behind, and stray pulls do not trigger pull-to-refresh mid-task
Avoid
Let a bottom sheet chain its scroll to the body - the page behind creeps, and an upward flick refreshes the tab and destroys form state
See how your website reads on a phone.
Run the free website health check on any site, then keep it easy to read with the Website Health Report each month.