11.4 Mobile Accessibility Guidelines

11.4.1 Platform accessibility settings

Most mobile platforms provide accessibility settings such as contrast between background and foreground text, invert colors, large text, grayscale, mono audio etc. Users select the relevant setting as per their requirement and expect all the apps to behave accordingly. All the accessibility options in the device settings should be reviewed and it must be ensured that each accessibility feature behaves as intended. For example, if a user chooses invert color option, and the app is already showing black text on a white background then it should show white text on black background which is easy on the eyes for many users with photosensitive eyes. Many other users without any well-known eye condition also find this easier for prolonged reading. Hence it MUST be ensured that platform accessibility features are optimally used and they behave as intended. App designers should also follow platform specific design guidelines.

11.4.2 UI Labels

Each UI element must have an accessible label for, content such as images, buttons and other controls. An accessible label is recognizable by assistive technology such as Voice over or Talk Back. labels that are embedded into an image must be avoided as they cannot be parsed by screen readers. Hence it MUST be ensured that Proper labels have been provided for all UI elements.

Following key points should be considered while labeling UI elements:

  1. A label must be precise and clear: Think about the purpose that the UI element serves. For example, label “Add to favourites” for adding an item to favourites. Action verbs that describe the purpose of the UI element must be used in order to provide appropriate labels.
  2. Timely Update:In case the functionality of the UI element changes, the label must be updated as well. For example, “Play” button must change to “Pause” and vice versa for media files. Updated labels make it easy for the users to interact with the app.
  3. Role and state information should not be provided as the as part of label: This information is provided separately through Accessibility API (described in Practice 3).For instance, “Play ”button to be labeled as “Play”, and not “Play button” because the button’s role will be indicated through accessibility API.
  4. Label strings should be localised: This is required for users using the applications in different languages.

11.4.3 Role information for UI elements

Every UI element can be identified visually with its look and feel. As users with blindness cannot perceive visual information, the role for a UI element MUST be available programmatically so that assistive technology can report this either through speech or Braille. In order to do so, use platform specific roles or traits for standard UI elements. For example, a button is announced as “Button” along with the label for assistive technology users. In case of custom UI elements, use platform accessibility API to report the role information.

11.4.4 Hints for active UI controls

A Hint is a brief, localized phrase that describes the results of an action on a UI control. It is like a tool tip that lets the user find out how to interact with the UI control. Hints are only required for UI controls that allow users some interaction, and are not required for UI elements such as labels or plain text. In case of custom UI controls, hints also report the screen reader gestures that users could perform to interact with the control. The standard UI controls have hints supplied by the APIs, but those hints might have to be changed depending on the usage. It MUST be ensured that hints are provided for all active UI control elements.

11.4.5 State information for a UI control

In addition to the role of a UI control, assistive technologies must identify the current state of a UI control. For example, the state of checkbox checked/ unchecked, tab selected or not, a push button pressed or not etc. should be notified. This information must also be reported as soon as it is changed. The standard UI controls provide this information by default, but for custom controls, this information must be supplied by platform specific accessibility APIs. The changes of state of UI controls MUST be dynamically updated and accurately available to the assistive technologies.

11.4.6 Grouping of Related UI elements

Related UI elements such as book title and author name for a book MUST be grouped together so that assistive technologies can present it as a single UI element, reducing the gestures for interaction. This also helps to increase the touch target so that users with low vision, users having motor difficulties and users with big fingers can more easily interact with it. The following points are important for grouping related elements:

  1. A group must have only one actionable UI control.
  2. Updating UI controls such as progress bar must not be grouped with any other control as users need only the updated information.

11.4.7 Simple interface and enough spacing between elements

UI should be clean and simple. Vertical and horizontal scrolling should be avoided. This allows users with low vision to zoom and interact with the controls with ease. A non-interactive space of at least one point for iOS or 1 DP for android MUST be provided between actionable UI elements. This allows users with low vision, users having motor difficulties and users with big fingers to avoid touching a wrong UI element.

11.4.8 Touch Target

Many users find it difficult to interact with small screen elements. It could be due to big or unsteady fingers or motor or visual difficulties. So, the touch targets MUST be at least 9x9mm regardless of screen size.

11.4.9 Bring focus to the active UI control

Since Mobile screens are small, all the UI elements cannot fit on the screen at a time. UI elements such as buttons that take less space are used to bring up other UI elements such as dropdowns. For example, users would activate the “MM” button to bring up the month dropdown. In such scenarios, the dropdown should get the focus when the user activates the button. If the focus is not set properly, blind and low vision users may not be able to realize that the UI has changed.

It sometimes takes many attempts to find out the new elements and if such interactions are time sensitive, a timeout could occur and the user would have to start all over again. Even without timeouts, new users could find it difficult to manage such interactions thus impacting the user experience. Therefore focus MUST be brought to the active UI control.

11.4.10 Custom actions for context specific UI

When a UI control has context specific menu items, users MUST be informed that such a menu is present and must be able to activate those menu items. A Custom Action is an effective technique to support such an interaction. Both Android and iOS provide Custom Actions that are available to assistive technology users. When an element with a custom action is focused, assistive technology lets the user know that such actions are available and then users can use well known gestures to perform those actions. Alternatively, use the accessibility API to report to the user what new UI elements are available and where such elements are present on the screen. This way users can locate those elements. This technique should only be used if Custom Actions are not available.

11.4.11 Logical and meaningful sequence

Screen reader mobile users rely on gestures to navigate and interact with the content and the UI controls. Content when navigated using the screen reader gestures, MUST form a meaningful sequence. The controls on the mobile screens and the interaction produced need to be logical.

11.4.12 Screen orientation

Assistive technology users could lock screen orientation to avoid interference with their interaction with the device. Hence the following should be followed while handling screen orientation:

  1. If the user has turned on “Locked Orientation” option for iOS or disabled the Auto-rotate screen option for Android, then the app should not try to change the screen orientation.
  2. If Screen orientation change is not disabled then it should be ensured that the screen orientation change is not disruptive and the focus does not move from the focused screen element.
  3. Screen orientation change should be reported using accessibility API.
  4. Report Screen orientation at the start if it is different from the default setting when screen orientation change is disabled. Otherwise, the change should be reported every time the orientation changes.

11.4.13 Resizable Content

Users with low vision may need to increase the size of the UI elements to be able to see well. The app MUST resize its UI elements in accordance with device settings for text size.

11.4.14 Color contrast

Users with low vision or users in poor lighting condition would find it difficult to see the UI elements on the screen if the foreground elements cannot be differentiated from the background. Therefore, color contrast ratio between foreground text for up to 18 point font and background MUST be at least 4.5:1.

11.4.15 Color or shapes MUST not be used to communicate important information

Relying only on color or shape to communicate important information can be problematic for certain persons with disabilities such as users with color blindness or users with blindness. The following considerations are critical:

  1. Text equivalence for color coded or shape dependent information must be added. For example, if an app has a required field, then it could provide the word (Required) if the space permits or use placeholders.
  2. The app must disable the button used to move the menu forward until the field is filled-out. Just relying on the shape of a button to indicate the disabled state does not work for many users with disabilities.
  3. Apps must not use color-based references such as Click on Red or Square button; instead have text references such as Click on Next button.

11.4.16 Onscreen keyboard and hardware keyboard

Mobile platforms provide support for both onscreen keyboard and hardware keyboard. App designers must ensure that both are accessible with assistive technology such as magnifier or a screen reader. Note the following points while developing and testing the input interface:

  1. Do not automatically change focus: If a user is entering data and the focus shifts automatically, the user would find it difficult to enter data. Focus MUST be changed only when the user activates a UI element that is designated for confirming an action such as the Submit button.
  2. Select the correct onscreen keyboard: It MUST be Ensured that the appropriate keyboard is invoked by the app depending on the type of field or the data that needs to be provided by the user. For example, the appropriate on-screen keyboard must be invoked for normal text, numerical data, email address or web address. This recommendation is not only helpful for users with disabilities; it also enhances the comfort of other users.
  3. Though many users work with the onscreen keyboard, others still prefer using a hardware keyboard that comes built-in or is connected with mobile devices via Bluetooth. Apps must be tested with hardware keyboards as well. It MUST be ensured that Apps are compatible with hardware keyboard.

11.4.17 Gesture commands

Complex gesture patterns make application usage difficult for those who do not have use of all of their fingers, or use the device with a single-hand. Gestures that require 3 or more fingers to interact with UI elements MUST be avoided. If such complex patterns cannot be avoided, provide an alternate to perform the same action or allow the user to create a custom gesture. For example, an added setting may be provided to customize gestures as per user requirements.

11.4.18 Time Provided for action

Many users require extra time to be able to finish an action. Session timeouts MUST be avoided. If a timeout cannot be avoided, then an option MUST be provided for users to extend the time limit before the timeout occurs. Also, make sure that the time extension element focus is properly set.

11.4.19 Captions and subtitles/transcripts

Many users who have hearing difficulties or who find the language in the audio difficult to understand would need captions or transcripts that help them to understand the content of the audio. Captions MUST be provided for all audio content and subtitles/transcript MUST be provided for all video content that is accompanied by audio.

11.4.20 Audio descriptions for video content

Users with blindness may find it difficult to understand important visual information which is not available in the audio format. If the application contains video that does not have an audio equivalent, audio description for the video content that is crucial for blind users to understand the content MUST be provided. It is not required to provide audio for decorative and nonessential video content.

11.4.21 Flashing content

Some users get seizures if any content flashes more than 3 times per second. Therefore, it MUST be ensured that no content flashes more than 3 times in one second.

11.4.22 Meaningful Notifications and Error Messages

Notifications are meant to inform and guide users. They can be error messages, alerts, instructions, and changes of state, responding to an interaction or a range of other cues. Use operating system alerts or inline messages.It should be Ensured that the notifications are audible and can be read by screen readers. Preference should be given to operating system alerts as they are easier to understand. Custom made notifications should be clear and precise.