Mobile Accessibility Guidelines - Text Equivalents

Roles, traits and properties must

Elements must have accessibility properties set appropriately.

Users of assistive technology, such as screen readers, rely on accessibility properties such as role, name, value, and state to be set appropriately in order to know how to identify and interact with an element or object.

For example, on iOS a trait of ‘button’ must be set in order for a VoiceOver user to know what the element does and how to interact with it. With HTML content, if a VoiceOver user hears “button” they know to use the Enter key, if they hear “link” they know to use the Space Bar.

Standard elements generally provide roles, traits and properties by default within the platform. Custom elements and objects will require all accessibility roles, traits and properties to be set.

iOS

In iOS, roles and states are referred to as traits. Traits can be set either through the Identity Inspector, by selecting the desired trait(s) for the control within the Accessibility panel, or at code level. Page elements can have one or more traits, which include the examples below.

Make sure that an accessible name is applied (through the accessibilityLabelattribute) to all page elements provided with a trait.

A full list of traits is available in Apple’s API reference.

Android

Roles are assigned automatically when using standard user interface, hence aim to use common native controls instead of custom solutions as much as possible, as the necessary behaviour and semantics are built in by default.

If custom controls must be used, use the contentDescription attribute to identify the role. Examples of common controls include:

  • Button
  • CheckBox
  • EditText (a text field)
  • Picker (time and/or date picker)

A full list of common controls is available on the website.

Certain native controls, such as CheckBox and RadioButton controls, handle state information natively through the isChecked method. In other cases, such as indicating that content can be expanded or collapses, this information must be provided through the contentDescription attribute.

Android Pass Example

<ImageButton
  android:id="@+id/expand_button"
  android:src="@drawable/expand_button_source"
  android:focusable="true"
  android:importantForAccessibility="yes"
  android:contentDescription="Expand the main content section" />

HTML

Aim to use native HTML elements for interface controls, as the required behaviour and semantics are built in by default. For example, use a native button element for buttons, rather than a span or div element provided with additional JavaScript.

Aim only to develop custom interface controls in situations where the visual design constraints rule out the use of a particular native element, or where the element does not yet exist in HTML. In such cases, apply the relevant markup to ensure that the correct semantics and behaviour are exposed to the device’s built in assistive technologies. In particular, refer to the to ensure that custom widgets follow recognisable patterns.

HTML Pass Example

Example 1

Standard control

<input type="checkbox" id="c1" /><label for="c1">Remember me</label>

Example 2

ARIA supported tree view with fall-back

<ul role="tree">
    <li aria-level="0" aria-expanded="true" role="treeitem">
        <a href="...">TV Shows <span class="offscrn"> - Expanded</span></a>
        <ul>
            <li aria-level="1" role="treeitem"><a href="...">Comedy</a></li>
            <li aria-level="1" role="treeitem"><a href="...">Drama</a></li>
            <li aria-level="1" role="treeitem"><a href="...">Sports</a></li>
        </ul>
    </li>
    <li aria-level="0" aria-expanded="true" role="treeitem">
        <a href="...">Radio Shows <span class="offscrn"> - Expanded</span></a>
        <ul>
            <li aria-level="1" role="treeitem"><a href="...">News</a></li>
            <li aria-level="1" role="treeitem"><a href="...">Soap</a></li>
            <li aria-level="1" role="treeitem"><a href="...">Sports</a></li>
        </ul>
    </li>
</ul>

Testing

Procedures

  1. Activate the screen reader.
  2. Gain focus on the individual object, element, or controls.
  3. Verify that the announced item label matches the on-screen text or contains additional supplementary information to assist with non visual access of the item.
  4. Verify that the announced role of the item matches the perceived visual role.
  5. If applicable, verify that the value of the item is properly announced by the screen reader.
  6. Verify that the state of the element is announced properly.
  7. If applicable, toggle the state of the item and verify that the screen reader announces the correct state change.

Outcome

The following check is true:

  • Object, elements, or controls including their labels, roles, values, states and state changes are correctly announced by a screen reader.