Please note, this is a STATIC archive of website developer.mozilla.org from November 2016, cach3.com does not collect or store any user information, there is no "phishing" involved.

Mobile accessibility checklist

This document provides a concise checklist of accessibility requirements for mobile app developers. It is intended to continuously evolve as more patterns arise.

Colour

  • 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.

Visibility

  • 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 hidden attribute or visibility or display style properties.
    • Unless absolutely unavoidable, aria-hidden attribute SHOULD NOT be used.

Focus

  • 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 button, link, or checkbox.
  • Focus should be handled in a logical order and consistent manner.

Text Equivalents

  • 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 aria-label, aria-labelledby, or aria-describedby.
  • Images of text MUST be avoided.
  • All form controls MUST have labels (<label> elements) for the benefit of screen reader users.

Handling State

  • 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 aria-checked, aria-disabled, aria-selected, aria-expanded, and aria-pressed.

General Guidelines

  • 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 banner, complementary, contentinfo, main, navigation, search.
  • Touch event handlers MUST only be triggered on the touchend event.
  • 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.

 

Document Tags and Contributors

 Contributors to this page: mfaure, chrisdavidmills
 Last updated by: mfaure,