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

Revision 593437 of Mobile accessibility checklist

  • Revision slug: Web/Accessibility/Mobile_accessibility_checklist
  • Revision title: Mobile accessibility checklist
  • Revision id: 593437
  • Created:
  • Creator: chrisdavidmills
  • Is current revision? No
  • Comment

Revision Content

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 ({{ htmlelement("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.)

Note: The original version of this document was written by Yura Zenevich.

 

Revision Source

<div class="summary">
 <p><span class="seoSummary">This document provides a concise checklist of accessibility requirements for mobile app developers. It is intended to continuously evolve as more patterns arise.</span></p>
</div>
<h2 id="Colour">Colour</h2>
<ul>
 <li>Colour contrast <strong>MUST</strong> comply with <a href="https://www.w3.org/TR/WCAG/">WCAG 2.0</a> AA level requirements:
  <ul>
   <li>Contrast ratio of 4.5:1 for normal text (less than 18 point or 14 point bold.)</li>
   <li>Contrast ratio of 3:1 for large text (at least 18 point or 14 point bold.)</li>
  </ul>
 </li>
 <li>Information conveyed via colour <strong>MUST</strong> be also available by other means too (underlined text for links, etc.)</li>
</ul>
<div class="note">
 <p><strong>Note</strong>: Jon Snook has written a useful <a href="https://snook.ca/technical/colour_contrast/colour.html">Colour Contrast Checker</a> 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.</p>
</div>
<h2 id="Visibility">Visibility</h2>
<ul>
 <li>Content hiding techniques such as zero opacity, z-index order and off-screen placement <strong>MUST NOT</strong> be used exclusively to handle visibility.</li>
 <li>Everything other than the currently visible screen <strong>MUST</strong> be <em>truly</em> invisible (especially relevant for single page apps with multiple <em>cards</em>):
  <ul>
   <li><strong>USE</strong> the <code>hidden</code> attribute or <code>visibility</code> or <code>display</code> style properties.</li>
   <li>Unless absolutely unavoidable, <code>aria-hidden</code> attribute <strong>SHOULD NOT</strong> be used.</li>
  </ul>
 </li>
</ul>
<h2 id="Focus">Focus</h2>
<ul>
 <li>All activatable elements <strong>MUST</strong> be focusable:
  <ul>
   <li>Standard controls such as links, buttons, and form fields are focusable by default.</li>
   <li>Non-standard controls <strong>MUST</strong> have an appropriate <a href="https://www.w3.org/TR/wai-aria/roles">ARIA Role</a> assigned to them, such as <code>button</code>, <code>link</code>, or <code>checkbox</code>.</li>
  </ul>
 </li>
 <li>Focus should be handled in a logical order and consistent manner.</li>
</ul>
<h2 id="Text_Equivalents">Text Equivalents</h2>
<ul>
 <li>Text equivalent <strong>MUST</strong> be provided for every non-strictly presentational non-text element within the app.
  <ul>
   <li>Use <em>alt</em> and <em>title</em> where appropriate (<em>s</em>ee Steve Faulkner's post about <a href="https://blog.paciellogroup.com/2013/01/using-the-html-title-attribute-updated/">Using the HTML title attribute</a> for a good guide.)</li>
   <li>If the above attributes are not applicable, use appropriate <a href="https://www.w3.org/WAI/PF/aria/states_and_properties#global_states_header">ARIA Properties</a> such as <code>aria-label</code>, <code>aria-labelledby</code>, or <code>aria-describedby</code>.</li>
  </ul>
 </li>
 <li>Images of text <strong>MUST</strong> be avoided.</li>
 <li>All form controls <strong>MUST</strong> have labels ({{ htmlelement("label") }} elements) for the benefit of screen reader users.</li>
</ul>
<h2 id="Handling_State">Handling State</h2>
<ul>
 <li>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 <a href="https://www.w3.org/TR/wai-aria/states_and_properties#attrs_widgets_header">ARIA States</a> such as<code> aria-checked</code>, <code>aria-disabled</code>, <code>aria-selected</code>, <code>aria-expanded</code>, and <code>aria-pressed</code>.</li>
</ul>
<h2 id="General_Guidelines">General Guidelines</h2>
<ul>
 <li>An app title <strong>MUST</strong> be provided.</li>
 <li>Headings <strong>MUST</strong> not break hierarchical structure
  <pre class="brush: html">
&lt;h1&gt;Top level heading&lt;/h1&gt;
  &lt;h2&gt;Secondary heading&lt;/h2&gt;
  &lt;h2&gt;Another secondary heading&lt;/h2&gt;
    &lt;h3&gt;Low level heading&lt;/h3&gt;</pre>
 </li>
 <li><a href="https://www.w3.org/TR/wai-aria/roles#landmark_roles_header">ARIA Landmark Roles</a> <strong>SHOULD</strong> be used to describe an app or document structure, such as <code>banner</code>, <code>complementary</code>, <code>contentinfo</code>, <code>main</code>, <code>navigation</code>, <code>search</code>.</li>
 <li>Touch event handlers <strong>MUST</strong> only be triggered on the <code>touchend</code> event.</li>
 <li>Touch targets <strong>MUST</strong> be large enough for the user to interact with (see the <a href="https://www.bbc.co.uk/guidelines/futuremedia/accessibility/mobile/design/touch-target-size">BBC Mobile Accessibility Guidelines</a> for useful touch target size guidelines.)</li>
</ul>
<p><strong>Note</strong>: <a href="https://www.tanaguru.com/">Tanaguru's automated accessibility testing service</a> 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.)</p>
<p><strong>Note</strong>: The <a href="https://yzen.github.io/2014/04/30/mobile-accessibility-checklist.html">original version of this document</a> was written by <a href="https://yzen.github.io/">Yura Zenevich</a>.</p>
<p>&nbsp;</p>
Revert to this revision