Mobile Accessibility Guidelines

Overview

Most websites and web applications are designed and developed primarily on large desktop monitors, but are most commonly consumed on mobile devices and other smaller screens. This has myriad usability implications, including accessibility.

All general accessibility guidelines apply to mobile devices. WCAG 2.0 was developed before mobile browsing was ubiquitous; most of these criteria are part of the WCAG 2.1 specification, but you are encouraged to adhere to them now, both for general usability and to future-proof your services. 

Guidelines

Minimize Scrolling

  • Content can scroll in one dimension (commonly vertical) but should not scroll in two dimensions.  
    • Exceptions include maps, data tables, diagrams, and presentations.
  • Embeds are preferable to Iframes, as they tend to behave better on smaller screens.
  • If using data tables, consider using CSS solutions such that each row as presented on a desktop gets styled as its own mini-table on mobile.

A basic implementation of how to use CSS to make tables fit on mobile devices. The break point for mobile is set at 600px; resize your browser to see this behavior.

Ensure Content is Appropriately Sized

  • Annual phone releases almost always include higher resolutions than their predecessors. Ensure content is appropriately sized for legibility on high-res mobile devices, and use relative font sizing versus absolute sizes.
  • Don’t disable the Viewport meta element, this prevents users from pinching the screen to zoom in and out, and resize text.
  • Ensure hit boxes / touch targets are appropriately sized. Use a minimum of 9mm x 9mm touch targets on a physical device, and if your touch target is close to this minimum size, ensure there is dead space between the target and adjacent targets to minimize risk of mis-selecting.
  • Content and functionality needs to be visible and usable in both vertical and horizontal orientations.

Design for Alternate Inputs

  • Some users struggle with multi-finger gestures, like pinching or multi-finger swiping. All vital functionality should be enabled, or be allowed, with single pointer gestures.
  • Single-pointer gestures have a higher risk of unintentionally performing an action, so make sure at least one of the following is true:    
    • The down-event does not execute the function. A user can swipe away from a button press, and it does not perform the button action (the behavior completes on the up-event).
    • There is a mechanism to undo or cancel the single-pointer gesture.
    • Completing the function on the down-event is a vital and immutable effect of the service.
  • Some users use Bluetooth or USB keyboards on their mobile devices. Make sure “hamburger menus” and other mobile-specific UI elements work with the keyboard alone, and do not require touch gestures.

Follow Standard Web Patterns

  • Touch gestures typically do not allow for hover states. This makes it more difficult for some people to ascertain the intention behind a UI element before they interact with it. Use standard design patterns, like buttons with rounded corners and drop shadows, to minimize the risk of ambiguous functionality.

How to Test

Test content manually, ideally with physical devices. Browser-based emulators are sufficient for development and preliminary testing, but whenever possible, use at least 1 physical Android device and 1 physical iOS device to confirm mobile behavior.