This document provides a concise checklist of accessibility requirements for mobile app developers. It is intended to continuously evolve as more patterns arise.
- Colour contrast MUST comply with WCAG 2.0 AA level requirements:
- Contrast ratio of 4.5:1 for normal text (less than 18 point or 14 point bold.)
- Contrast ratio of 3:1 for large text (at least 18 point or 14 point bold.)
- Information conveyed via colour MUST be also available by other means too (underlined text for links, etc.)
Note: Jon Snook has written a useful Colour Contrast Checker that is useful for checking contrast between a background and foreground colour. Alternatively, the Tanaguru Contrast-Finder does a similar job, but also suggests similar but better contrasting colours for you to consider using.
- Content hiding techniques such as zero opacity, z-index order and off-screen placement MUST NOT be used exclusively to handle visibility.
- Everything other than the currently visible screen MUST be truly invisible (especially relevant for single page apps with multiple cards):
- USE the
- Unless absolutely unavoidable,
aria-hiddenattribute SHOULD NOT be used.
- USE the
- All activatable elements MUST be focusable:
- Standard controls such as links, buttons, and form fields are focusable by default.
- Non-standard controls MUST have an appropriate ARIA Role assigned to them, such as
- Focus should be handled in a logical order and consistent manner.
- Text equivalent MUST be provided for every non-strictly presentational non-text element within the app.
- Use alt and title where appropriate (see Steve Faulkner's post about Using the HTML title attribute for a good guide.)
- If the above attributes are not applicable, use appropriate ARIA Properties such as
- Images of text MUST be avoided.
- All form controls MUST have labels (
<label>elements) for the benefit of screen reader users.
- Standard controls such as radio buttons and checkboxes are handled by the operating system. However, for other custom controls state changes must be provided via ARIA States such as
- An app title MUST be provided.
- Headings MUST not break hierarchical structure
<h1>Top level heading</h1> <h2>Secondary heading</h2> <h2>Another secondary heading</h2> <h3>Low level heading</h3>
- ARIA Landmark Roles SHOULD be used to describe an app or document structure, such as
- Touch event handlers MUST only be triggered on the
- Touch targets MUST be large enough for the user to interact with (see the BBC Mobile Accessibility Guidelines for useful touch target size guidelines.)
Note: Tanaguru's automated accessibility testing service provides a useful way to uncover some of the accessibility errors that can occur on a web page, or installed web app (e.g. Firefox OS.) You can find more about the technical implementation of Tanaguru, as well as how to contribute to the project, at tanaguru.org.
Note: The original version of this document was written by Yura Zenevich.