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

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 user interface components with visible text (or image of text) as labels must have the same text available in the programmatic name of the component. WCAG 2.1: Label in name
  • 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

 

Orientation

  • Content should not be restricted to a single orientation, such as portrait or landscape, unless essential. WCAG 2.1: Orientation
    • Examples of when an orientation is esssential is a piano application or a bank cheque.

 

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.
  • For touch events, at least one of the following must be true (WCAG 2.1: Pointer Cancellation):
    • The down-event should not be used to trigger any action
    • The action is triggered on the up event and an option to abort the action before its completion is available or an option to undo the action after its completion
    • The up-event will undo any action that was triggered on a down event
    • It is essential to trigger the action on the down event. For example, playing a game or a piano application.
  • Touch targets MUST be large enough for the user to interact with (see the BBC Mobile Accessibility Guidelines for useful touch target size guidelines).

 

Document Tags and Contributors

Last updated by: tanazyazdani,