Mobile Accessibility Checklist

Over half of all web traffic comes from mobile devices, yet mobile accessibility is often an afterthought. This checklist covers touch interactions, gestures, screen reader support, responsive layout, and device-specific concerns. Your progress is saved automatically.

Interactive Mobile

0 of 24 items complete

Touch and Target Size

Touch targets are at least 24x24 CSS pixels WCAG 2.2 requires a minimum of 24x24px (SC 2.5.8). Aim for 44x44px for primary actions to accommodate users with motor impairments.
Adequate spacing exists between adjacent touch targets Prevent accidental taps by ensuring at least 8px of space between interactive elements, especially in navigation and form controls.
Interactive elements are placed away from screen edges Edge-positioned buttons conflict with system gestures (swipe-back, swipe-up). Keep interactive elements within the safe area.
Actions activate on up-event, not down-event Use click or touchend, not touchstart. This allows users to cancel by moving their finger off the target (SC 2.5.2).

Gestures and Input

Multi-point and path-based gestures have single-pointer alternatives Pinch-to-zoom, swipe carousels, and multi-finger gestures must have button or tap alternatives (SC 2.5.1).
Drag operations have accessible alternatives Sortable lists and sliders must be operable via taps or buttons, not drag-only (SC 2.5.7).
Device motion is not the only way to perform actions Shake-to-undo, tilt-to-scroll, or similar motion inputs must have UI-based alternatives. Users can disable motion (SC 2.5.4).
Correct virtual keyboard is triggered for each input type Use type="email", type="tel", type="number", and inputmode to display the most efficient keyboard layout.
Custom gestures are documented and discoverable If your interface uses custom swipe or long-press interactions, provide on-screen hints or a help section explaining them.

Screen Reader and Assistive Technology

Content is tested with VoiceOver (iOS) and TalkBack (Android) Navigate the entire interface using swipe gestures. Verify all elements are announced with correct name, role, and state. Screen Reader Testing guide
Focus order is logical when using swipe navigation Screen reader swipe-to-next moves through elements in a meaningful sequence. Visually hidden elements should not appear in the swipe order unless needed.
Dynamic content changes are announced Loading states, inline validation, and content updates must use live regions so screen reader users are informed of changes. ARIA guide
Modals and overlays trap focus correctly on mobile When a modal is open, screen reader users must not be able to swipe to content behind it. Use aria-modal="true" and manage focus. Modal Dialog pattern
Decorative elements are hidden from assistive technology Use aria-hidden="true" and alt="" for decorative icons and images so screen readers skip them.

Responsive Layout and Viewport

Content reflows at 320px viewport width without horizontal scrolling All content must be usable in a single column at 320 CSS pixels (equivalent to 1280px at 400% zoom) with no loss of information (SC 1.4.10).
Pinch-to-zoom is not disabled Never use maximum-scale=1 or user-scalable=no in the viewport meta tag. Users must be able to zoom (SC 1.4.4).
Content works in both portrait and landscape orientation Don't lock orientation unless essential (e.g., a piano app). Users mounted in wheelchairs or stands may have a fixed orientation (SC 1.3.4).
Text remains readable without zooming Body text should be at least 16px. Avoid very small text for labels, captions, or legal disclaimers that users need to read.
Fixed/sticky elements don't obscure content on small screens Sticky headers, cookie banners, and floating buttons can cover large portions of small viewports. Ensure they don't block content or interactive elements (SC 2.4.11).

Motion, Media, and Performance

Animations respect prefers-reduced-motion Use @media (prefers-reduced-motion: reduce) to disable or simplify animations. Many mobile users enable reduced motion in system settings (SC 2.3.3).
Auto-playing media can be paused or stopped Auto-playing video or audio must have visible pause controls. Never autoplay with sound (SC 1.4.2, 2.2.2).
Dark mode maintains sufficient contrast ratios Test all text and UI elements in both light and dark mode. Dark backgrounds can reduce perceived contrast. Color Contrast guide
Page loads and becomes interactive within a reasonable time Slow-loading pages on mobile networks can trigger timeouts and frustrate users of assistive technology. Optimize critical rendering path and provide loading indicators.
Content is usable on low-bandwidth or offline-capable connections Ensure graceful degradation when images fail to load or scripts are delayed. Alt text and semantic HTML provide fallback content.

Frequently asked questions

What touch target size should I use?

Minimum 24×24 CSS pixels per WCAG 2.5.8 (AA). The recommended floor is 44×44 (Apple's iOS guidelines) or 48×48 (Material Design). Use padding to expand the click area without inflating the visual size. The Developer checklist covers this for all platforms.

Do I need to support pinch-to-zoom?

Yes. Don't set user-scalable=no or maximum-scale=1 in the viewport meta tag. Low-vision users rely on zoom to read content. Some browsers ignore these directives entirely, but they signal hostile intent and may fail accessibility audits.

How should I handle long-press, swipe, and other gestures?

Provide single-tap alternatives. Per WCAG 2.5.1, any multi-point or path-based gesture (pinch, swipe, drag) must also work as a simple tap on a button. Don't lock essential actions behind dexterity-requiring gestures.

Do mobile screen readers (VoiceOver, TalkBack) behave like desktop ones?

Similar, but with different navigation gestures. VoiceOver uses swipe and double-tap; TalkBack uses swipe and tap. Both expose your DOM via the accessibility tree, so semantic HTML and proper ARIA work the same. The main mobile-specific issues are focus management on dynamic content and touch-target size.

How do I test on iOS without a Mac?

BrowserStack offers iOS device cloud access with VoiceOver enabled. Or borrow an iPad/iPhone and enable VoiceOver in Settings → Accessibility. For developer tooling, Safari on Mac is the only browser that can remote-inspect iOS Safari. Many issues reproduce on Mac Safari with VoiceOver, so test there first if you have a Mac.

What about device rotation and orientation locks?

WCAG 1.3.4 prohibits restricting content to a single orientation unless essential (e.g., a piano app). Users with mounted devices may be unable to rotate. Test both portrait and landscape, ensure content reflows cleanly, and don't lock orientation programmatically without a strong reason.