Mobile accessibility: target sizes, gestures and reflow that matter

Mobile accessibility has no standard of its own: WCAG 2.2 applies to small screens. Target size, reflow, gestures and Apple and Android guidance.

info Quick Definition

Mobile accessibility is the application of accessibility guidelines to apps and sites on small, touch screens. There is no separate standard: the W3C says mobile accessibility is covered by existing guidelines, and WCAG 2.2 is the reference. In practice that means touch targets big enough, content that rearranges when enlarged, and alternatives to gestures.

Why is mobile different?

On mobile, people interact with a finger, often with one hand, sometimes on the move and always on a small screen. The W3C notes that its mobile work addresses issues such as touchscreens, small screen sizes, input methods (speech, for example) and use in settings such as bright sunlight. A 16-pixel button is easy to see and hard to tap. A menu that only opens with a drag can be impossible for someone with a tremor or only one hand.

Mobile also brings built-in aids: screen readers (VoiceOver on iOS, TalkBack on Android), system text enlargement and contrast controls. Designing well means not blocking them.

How big should touch targets be?

WCAG offers two levels, and the platforms have their own numbers:

Source	Value	Note
WCAG 2.5.8, Target Size (Minimum), AA	24 × 24 CSS pixels	Allows smaller targets with sufficient spacing
WCAG 2.5.5, Target Size (Enhanced), AAA	44 × 44 CSS pixels
Apple, accessibility guidelines	44 × 44 points by default on iOS and iPadOS; minimum of 28 × 28	Apple asks you to strive for each platform’s recommended size
Android, accessibility help	At least 48 × 48 dp, with 8 dp or more between targets	The touch area can extend past the drawn element, with padding

Criterion 2.5.8 has exceptions: undersized targets with enough spacing (a 24-pixel circle centered on each must not intersect another target), an equivalent control on the same page, links inside a sentence, controls determined by the browser, and cases where the presentation is essential. It also does not depend on zoom: enlarging the page does not make a small button pass. For the design detail, see touch targets.

What about reflow, text and orientation?

Criterion 1.4.10, Reflow (AA), requires content to be presented without loss of information or functionality and without two-dimensional scrolling at 320 CSS pixels wide for vertically scrolling content. The W3C clarifies that this equals a 1280-pixel viewport at 400% zoom. In practice, content must stack into a single column. There are exceptions for what needs two dimensions to make sense, such as maps, diagrams, data tables or games.

For fixed bars and menus, the W3C strongly suggests that at small viewport sizes they switch to static positioning, and that they do not fully hide the focused element. Criterion 1.4.4, Resize Text (AA), requires that text can be enlarged up to 200 percent without loss of content or functionality. Apple points the same way: it recommends letting people enlarge text by at least 200 percent and adopting Dynamic Type, the system text-size setting.

Criterion 1.3.4, Orientation (AA), asks you not to restrict the view to a single orientation unless it is essential. Someone whose phone is fixed to a mount may need landscape mode.

How do you design alternatives to gestures?

Criterion 2.5.7, Dragging Movements (AA), requires that any functionality using dragging can be done with a single pointer without dragging, unless dragging is essential. Its example is the slider: tapping the track moves the control to that position.

Criterion 2.5.1, Pointer Gestures (Level A), requires that functions using multipoint or path-based gestures can be operated with a single pointer without a path-based gesture. Its official examples are a carousel with forward and back buttons in addition to swiping, and a map with plus and minus buttons in addition to pinching. System and browser gestures are out of scope, such as swiping back or normal page scrolling. On Android, the documentation adds that you can expose a custom action to accessibility services for anything done by dragging or swiping, so TalkBack, Voice Access or Switch Access can complete it. More detail in mobile gestures.

How do you audit a mobile app?

A short review that combines the guidelines above:

Tap with one hand, your dominant one, on the main screen. Note what you cannot reach or trigger by mistake.
Raise the system text to the maximum and check that nothing is cut off or overlaps.
Rotate the screen and verify that the task is still possible.
Do each task without drag or swipe gestures. If you cannot, an alternative is missing.
Test with VoiceOver or TalkBack: every control needs a label that explains its function. Android also asks for unique labels within a collection. To organize it, see screen reader testing.

Example

Illustrative example: a booking app has a calendar that moves with horizontal swipes and an 18-pixel close button in the top corner. In the audit, the team finds three problems: the button does not reach the minimum size or have enough spacing; the calendar offers no one-tap alternative to change months; and with the system text at maximum, the dates run off the screen. The fix: the button becomes 44 × 44 pixels, arrows appear to change months and the calendar reorganizes into a list on narrow screens.

When is this review NOT enough?

When the app depends on sensors such as the camera or the gyroscope. You have to test on real devices and offer alternatives.
When screen readers are involved. A visual review does not replace testing with VoiceOver or TalkBack.
When there are no tests with people who have access needs. An audit against criteria is a minimum, not a substitute.

Common mistakes

Assuming mobile does not need accessibility because it is a personal device.
Designing small buttons for aesthetics, without enlarging the touch area.
Using gestures as the only way to operate content.
Forgetting the system text at its maximum size.
Locking the orientation when it is not essential.
Testing only on desktop with zoom and believing that replaces a mobile test.

For the basis of the criteria, read WCAG explained. If you want to prioritize from the start, mobile-first design helps. And to plan tests with real users, see mobile usability testing.

Sources

Frequently asked questions

Is there an accessibility standard only for mobile?

No. The W3C states that it has no separate guidelines for mobile: mobile accessibility is covered by existing standards such as WCAG 2.2, which applies to mobile web, native apps and hybrid apps. There is also an informative draft, WCAG2Mobile, that explains how to apply it.

What minimum size should buttons have on mobile?

WCAG 2.2 (criterion 2.5.8, Level AA) asks for at least 24 × 24 CSS pixels, or sufficient spacing around the target. Level AAA (2.5.5) raises it to 44 × 44. Apple lists 44 × 44 points as the default size on iOS and Android recommends at least 48 × 48 dp.

What is reflow and why does it matter on mobile?

It is the ability for content to rearrange into a single column without losing information or requiring two-dimensional scrolling. WCAG 1.4.10 (Level AA) requires it at 320 CSS pixels wide, equivalent to a 1280-pixel viewport at 400% zoom.

Can a slider be used only with drag gestures?

No, according to WCAG 2.5.7 (Level AA). Any functionality that uses dragging must be operable with a single pointer without dragging, for example by tapping the slider track to move the control to that position.

Do I have to let people rotate the screen?

Yes, unless one orientation is essential. WCAG 1.3.4 (Level AA) requires that content does not restrict its view and operation to a single display orientation.