Mobile Accessibility Practices

These mobile accessibility practices are originally developed to enhance the guidelines of Indian government websites (GIGW). These mobile accessibility practices are a collaborative effort by stakeholders including efforts from Maxability. The mobile practice refered in section 6 Mobile Accessibility Practices are the testable statements.

Skip to

  1. Problem statement
  2. International position on mobile app standards
  3. Methodology and approach
  4. Purpose and objective
  5. Introduction and explanatory note
  6. Mobile Accessibility Practices
  7. Mobile Practice 1: Support Platform Accessibility Settings
  8. Mobile Practice 2: labels for UI Elements
  9. Mobile Practice 3: provide role for UI Elements
  10. Mobile Practice 4: Provide a hint for the UI Element
  11. Mobile Practice 5: The state of UI elements should be provided and it should be updated
  12. Mobile Practice 6: Group related UI elements
  13. Mobile Practice 7: Bring focus to the actionable UI element
  14. Mobile Practice 8: Provide mechanism to interact with UI elements that may not get focus
  15. Mobile Practice 9: Simple interface and Spacing
  16. Mobile Practice 10: Touch target should be at least 9 X 9
  17. Mobile Practice 11: Logical and Meaningful Sequence
  18. Mobile Practice 12: Handle layout change consistently
  19. Mobile Practice 13: the content should be resizable
  20. Mobile Practice 14: Enough contrast
  21. Mobile practice 15: Color should not be the only method to communicate important information
  22. Mobile Practice 16: onscreen keyboard and hardware keyboard should be accessible
  23. Mobile Practice 17: Simple gesture pattern
  24. Mobile Practice 18: enough time
  25. Mobile Practice 19: Provide captions for audio content
  26. Mobile Practice 20: provide audio description for video content
  27. Mobile Practice 21: Make sure that there is no content that flashes more than 3 times a second
  28. Contributors

1. Problem statement

The shift to digital governance and availability of assistive technologies have been both empowering as well as frustrating for persons with disabilities, who comprise approximately 150 million of the Indian population . Government initiatives such as the Digital India campaign are increasingly delivering basic functions of governance through information technologies. In the past year, the government, private sector and the world at large have embraced mobile applications as a preferred medium for user interactions and transactions. The Mobile Seva App Store hosts 790 government apps, which provide services including voter information, agricultural assistance, welfare scheme signups, and educational content provision. In addition, the overall app market in India has also grown rapidly, with almost 5 times as many apps downloaded in 2015 compared to the previous year . These include apps which let users access everyday services like transportation, communication and entertainment.

However, for persons with disabilities, many of these apps, and consequently the services they provide, are inaccessible and often impossible to use. Research in the past year that looked at several apps, both government and private, found that majority of the apps are inaccessible and unusable, especially for persons with low vision and blindness. . In many cases, there is no other recourse for persons with disabilities to avail themselves of the services which these apps provide.

Hence, despite the availability of technologies such as text to speech to enable access to information independently, the failure to adhere to accessibility principles has had the effect of denying access to critical resources and information. Instead of empowerment, there is a crippling effect on persons with different disabilities in multiple ways.

The Government of India has recognised that accessibility is a concern which it needs to address if it has to engage comprehensively and effectively with the public. The Guidelines for Indian Government Web sites (GIGW 2009 ), the National Policy on Universal Electronics Accessibility (2013) REF and most recently the Rights of Persons with Disabilities Act 2016 all require compliance with web accessibility standards and provision of public information and resources in accessible electronic format. The increasing adoption of mobile as an engagement platform hence necessitates the adoption of guidelines to ensure that applications are accessible and usable to persons with disabilities.

2. International position on mobile app standards

Presently there is no single uniform international standard on the accessibility of mobile apps. The W3C is working on a standard, which will take time to be published. In the meantime it has published some best practices, primarily based upon the WCAG 2.0. There are also guidelines available from Android, iOS, BBC and some to be found within 508. However, none of these are comprehensive and cannot be adopted as is. Links to these guidelines are provided in the reference section of this submission.

3. Methodology and approach

These mobile accessibility practices have been put together by a group of accessibility and technology experts from different organisations, most of whom are persons with disabilities themselves and have extensive experience in the domain of assistive technology. They draw upon the guidelines and best practices mentioned in the previous section, user surveys and interviews conducted amongst persons with different types of disabilities as well as any particular user experience insights gained by using Indian government/private apps.

4. Purpose and objective

Given that apps have already permeated the sphere of everyday life and the likelihood of meeting one’s daily needs without apps is becoming almost impossible, it is critical that this issue be addressed immediately. The purpose of submiting these mobile accessibility practices is hence to present a set of guidelines/ practices which will inform mobile app developers about how to create applications which will be accessible and usable to all persons, including persons with disabilities. These practices are not comprehensive and we recommend annual review so that these practices can be updated based on the feedback from users, developers and experts.

5. Introduction and explanatory note

The objective of these mobile accessibility practices is to help developers, designers and testers to create mobile apps that are universally accessible.

An accessible application is one which is usable by everyone irrespective of their abilities. These mobile accessibility practices are formulated after reviewing various globally accepted standards such as W3C Web Content Accessibility guidelines 2.0 (WCAG 2.0), Mobile Accessibility standards by BBC and a few carefully adapted requirements from the recommendations of W3C Mobile Accessibility Task Force. Wherever applicable, the platform specific accessibility references are also considered while drafting these mobile accessibility practices.

The Mobile Accessibility practices discussed below are not technology specific, but the examples are based on either Apple iOS or Google Android operating systems. The other mobile platforms are either not accessible or not used widely. The techniques to test or implement a specific practice may differ depending on the operating system.

Both the Android and iOS operating systems provide standardized mechanisms to communicate various attributes of a user interface element (UI Element) such as the label associated with a UI element, role of a UI element (such as whether it is a button or an edit control,) and state information (such as whether it is disabled, checked or pressed.) This mechanism is called Accessibility Application Programming Interface (API) and it provides reasonably good information for standard UI elements.

6. Mobile Accessibility Practices

6.1 Mobile Practice 1: Support 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. Review all the accessibility options in the device settings and make sure 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 sensitive eyes. This feature is also used by many users without any well-known vision defect as white text on a black background is easy to read.

6.2 Mobile Practice 2: Provide Proper Labels for UI Elements

Provide an accessible label for each UI element, such as images, buttons and other controls,,. An accessible label is recognizable by assistive technology such as Voiceover or TalkBack. Avoid labels embedded into an image as they cannot be parsed by screen readers.

Consider the following key points 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 Cart” for adding an item to cart. Consider using action verbs that describe the purpose of the UI element 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. Do not provide the role and state information 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 button’s role will be indicated through accessibility API.
  4. Localize the label strings: This is required for users using the applications in different languages.

WCAG 2.0 corresponding success criteria: 1.1.1, 1.3.1, 2.4.2, 3.3.2, and 4.1.2.

6.3 Mobile Practice 3: Provide 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, hence 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.

WCAG 2.0 corresponding success criteria: 1.3.1, 3.2.4 and 4.1.2.

6.4 Mobile Practice 4: Provide hints for Active UI Controls

Hint is a brief, localized phrase that describes the results of an action on a UI control. A hint is like a tool tip and it 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. For example, in a shopping website that has a button “Add” that adds items to the cart, the button could have the hint as “Adds the item to the cart”. Similarly, for a drag and drop widget, the hint can be “Double tap and hold until you hear a sound, then drag your finger to move the element to the desired location and lift the finger”. The standard UI controls have the hints supplied by the APIs, but those hints might have to be changed depending on the usage.

WCAG 2.0 corresponding success criteria: 3.3.2 and 3.3.5.

6.5 Mobile Practice 5: Provide state Information for UI Control

In addition to the role of a UI control, assistive technologies must identify the current state of a UI control such as checkboxes , tabs and buttons. Eg Notifying if a checkbox is checked/ unchecked, tab is selected or not, a push button is pressed or not etc. 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 the state must be dynamically updated and accurately available to the assistive technologies.

WCAG 2.0 corresponding success criterion: 4.1.2.

6.6 Mobile Practice 6: Group the related UI elements

Related UI elements such as song title and singer name for a song 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 (Explained in Practice 8) so that users with low vision, those have trimmers in hand can more easily interact with it.

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.

6.7 Mobile Practice 7: Design Simple Interface and Provide Enough Spacing

Make the UI clean and simple. Avoid vertical and horizontal scrolling. This allows low vision users to zoom and interact with the controls with ease. Provide non-interactive space between actionable UI elements of at least one point for iOS or 1 DP for android. This allows users with low vision, users having motor difficulties and users having fat fingers to avoid touching a wrong UI element.

6.8 Mobile Practice 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.

6.9 Mobile Practice 9: Bring Focus to the Active UI Control

Since Mobile screens are small, all the UI elements cannot be fit on the same screen to show at a glance. So UI elements that take less space such as buttons can be used to display another UI element e.g. dropdown. For example, users would activate “MM” button to bring up the month dropdown. For such scenarios, the dropdown should receive focus when the user activates the button. If the focus is not managed, blind and low vision users may not be able to realize that the interaction has happened. It sometimes takes many attempts to identify the newly added elements and if such interaction is time sensitive, session timeout could occur and user would have to restart the entire process. Even without timeout, new users could find it difficult to manage such interactions impacting the user experience.

WCAG 2.0 corresponding success criterion: 2.4.3.

6.10 Mobile Practice 10: Use custom actions for context specific UI controls

When a UI control has context specific menu items, users must know that such a menu is present and must be able to activate those menu items. 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 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 accessibility API to report to the user what new UI elements are available and where on the screen such elements are present. This way users can locate those elements. This technique should only be used if Custom Actions are not available.

WCAG 2.0 corresponding success criterion: 1.3.1.

6.11 Mobile Practice 11: Provide Logical and Meaningful Sequence

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

WCAG 2.0 corresponding success criterion: 1.3.2, 2.4.3.

6.12 Mobile Practice 12: Handle screen orientation change consistently

Assistive technology users could lock screen orientation to avoid interference with their interaction with the device.

Pay attention to the following points while handling screen orientation:

  1. Screen orientation change is disabled: If the user has turned on “Locked Orientation” option for iOS or disabled the Auto-rotate screen option for Android, then try not to change the screen orientation.
  2. Screen orientation change is not disabled: Make sure that the screen orientation change is not disruptive and the focus does not move from the focused screen element.
  3. Report screen orientation change using accessibility API: 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 orientation changes.

6.13 Mobile Practice 13: the content must be resizable

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

WCAG 2.0 corresponding success criterion: 1.4.4.

6.14 Mobile Practice 14: Minimum 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, Recommended color contrast ratio between foreground and background content is 7:1.

WCAG 2.0 corresponding success criteria: 1.4.3 and 1.4.6

6.15 Mobile practice 15: Color should not be the only way to communicate important information

Relying only on color to communicate important information can be problematic for certain persons with disabilities, Eg users with color blindness or users with blindness. Following considerations are required:

  1. App designers must add text equivalence for color coded information. 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.
  3. Apps must not use color-based references such as click on red button, instead have text references such as click on Next button.
  4. WCAG 2.0 corresponding success criteria: 1.4.1, 1.3.1 and 1.3.3.

    6.16 Mobile Practice 16: Support for 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 the 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: ensure that 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, 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. Apps must be compatible with hardware keyboard: Though many users work with the onscreen keyboard, others still prefer using hardware keyboard that comes built-in or is connected with mobile devices via Bluetooth. Therefore, apps must be tested with hardware keyboards as well.

    WCAG 2.0 corresponding success criteria: 2.1.1, 2.1.2, 3.2.1, 3.2.2 and 3.2.5.

    6.17 Mobile Practice 17: Keep the gestures Simple

    Avoid gestures that require 3 or more fingers to interact with UI elements. These complex gesture patterns make the use of application difficult for those who do not have the use of all of their fingers, or use the device single-handedly. 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 the gestures as per user requirements.

    6.18 Mobile Practice 18: Provide Enough Time

    Many users require extra time to be able to complete an action or submit a form. So, avoid session timeouts. If timeout cannot be avoided, then provide an option for users to extend the time limit before the timeout occurs. Also, make sure that the time extension element focus is properly set. For more information refer to WCAG 2.0 corresponding success criterion: 2.2.1.

    6.19 Mobile Practice 19: Provide captions for audio content

    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 text of the audio.

    WCAG 2.0 corresponding success criteria: 1.2.2, 1.2.4, 1.2.6, 1.2.8 and 1.2.9.

    6.20 Mobile Practice 20: provide audio description 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, provide audio description to the content that is crucial in understanding. It is not required to provide audio for decorative and non-essential video content.

    WCAG 2.0 corresponding success criteria: 1.2.1, 1.2.3, 1.2.5, 1.2.7, 1.2.8

    6.21 Mobile Practice 21: no content must flash for more than 3 times a second

    Some users get seizures if any content flashes more than 3 times per second. Therefore, it is recommended that no content flashes more than 3 times a second.

    WCAG 2.0 corresponding success criteria: 2.3.1 and 2.3.2.

    Reference

    Contributors

    Editorial

    • Dinesh Kaushal
      NVDA Project Manager, Publicis.Sapient
      E-mail:dineshkaushal@hotmail.com
    • Dr. Nirmita Narasimhan
      Policy Director, Centre for Internet and Society
      E-mail: nirmita@cis-india.org
    • Rakesh Paladugula
      Accessibility Engineer Adobe Systems, Founder Maxability.co.in.
      E-mail: rakesh@maxability.co.in
    • Srinivasu Chakravarthula
      E-mail: srinivasu.c@serveominclusion.com
    • Sujasree Kurapati
      Managing Director , Deque Software Private Limited
      E-mail: sujasree.kurapati@deque.com
  5. Additional Contributors

    • Dipendra Manocha
      President, National Association for the Blind, Delhi
      E-mail: dipendra.manocha@gmail.com
    • Manish Agrawal
      Director of Technology, Publicis.Sapient
      E-mail: manish10@gmail.com
    • Pranay Gadodia
      Disability Diversity Inclusion Expert
      E-mail pranaybg@yahoo.co.in
    • Pranav Lal
      E-mail: contact@security-writer.com
    • Prashant Naik
      Talking ATM India
      E-mail: pranaik@gmail.com
    • Prashant Ranjan Verma
      E-mail: pverma@daisy.org
    • Saidarshan Bhagat

      E-mail: sai.bhagat@gmail.com