Digital Accessibility in Mobile Applications

Accessibility is about treating everyone equal, and providing them the same opportunities, irrespective of what their ability or circumstances. With nearly 1 out of 5 people of the world population (nearly 20%) having one or the other form of disability, it is important that the world, including the digital world, be made accessible to everyone.

Digital accessibility is the ability of a website, mobile application, software or an electronic document, in understanding and navigating the contents of that application to a whole set of users, including users who have a disability that affects their visual, auditory, motor or cognitive abilities. Digital accessibility is referred as “A11y” also.

Why digital accessibility

With the advent of digital services, a level of independence has been achieved by people with disabilities which they had struggled to obtain previously. A mobile or web application that is accessible improves the user experience for all users irrespective of if they have disabilities or not. Multiple tools are available in mobile devices that support assistive technology. These tools (available at software and hardware level) support people with disabilities to better navigate and interact with the app or website content. In web and mobile applications, the main assistive technologies are screen readers/magnifiers; pinch and zoom support; external hardware keyboards with/without trackpads etc.

Digital Accessibility Principles and Standards

Digital Accessibility is defined using the Perceivable Operable Understandable Robust (POUR) principle.

Perceivable: User should be able to identify content and interface elements by means of any of their senses. This principle indicates that some users will be perceiving the system visually while for some others it would be based on sound or touch. So, the application should be usable for users irrespective of how they interact with the system.

Operable: An application is considered as operable when the interactive elements and overall application navigation could be completed by all users, which includes users with disabilities. For majority of the users what this indicates is the user can identify the control visually and operate the control by clicking or swiping. For few disabled users, they could use the application by using an external keyboard or voice commands.

Understandable: A consistent user interface both in presentation and format. The user interface needs to have a predictable design and usage pattern and should be appropriate in its voice and tone. Users should be able to understand the content and could easily learn and remember how to use the interface.

Robust: This is mainly from being compliant to standards and making the application to function on appropriate technologies.

Web Content Accessibility Guidelines (WCAG) is considered as the standard for making a mobile website or mobile application accessible. WCAG 2.0, Level AA is currently considered as the internationally recognized standard.  WCAG 2.0 was designed to be technology neutral and written to evolve with changing technologies.

Key Mobile Accessibility Issues

Accessibility should not be an afterthought but must be considered as part of all phases of the project: from requirements to design to development to testing. It will take more time and effort to fix issues in an already existing application than implementing it first time. Based on our experience, we are listing down the key accessibility issues that are seen in most mobile and web applications.

  • Not enabling pinch to zoom feature in apps and websites
  • For non-text contents, e.g. images, text alternates need to be provided
  • Placeholder texts disappearing on focus (screen readers fail to read) and usually have a low contrast impacting the WCAG requirement
  • Impact of inconsistent focus order to keyboard and screen reader users
  • Screen readers set inaccessible to success, failure or information messages
  • Focus issues on modal dialogs where the focus remains on the initial button and not on the modal dialog
  • Keyboard-only users will need the ability to move through accordion or hamburger menu
  • When custom / non-standard controls are created, those controls should also work for keyboard or screen readers
  • Applications need to support the user preference of Dynamic Type allowing users to specify preferred font size in the device
  • WCAG 2.0 level AA color contrast requirements related to contrast between background color and text
  • Correct keyboard type needs to be enabled based on the data the user needs to be entering

Accessibility considerations during requirements and design based on the POUR principles

Some of the key accessibility related items that needs to be covered in any mobile based application based on the POUR principles are listed below.

  • Text alternatives need to be available for non-text contents like images for screen readers
  • Text resize function to adjust text size based on device settings and zoom feature without loss of content needs to be supported
  • Content needs to be ordered in meaningful sequence if it needs to be read in a certain order
  • User instructions should not just rely solely on sound, shape, size, color or visual location. Support for multiple options with change in color and text or color and shape combinations.
  • Sufficient color contrast with text and background colors must be provided
  • Allowing multiple modes of notification that can be received by persons with visual and/or hearing impairments
  • Description and sign language could be provided for prerecorded videos along with captions
  • Textual alternatives need to be provided for audio-only information


  • Clear and simple headings need to be provided for the content
  • Clear and informative links
  • Visible focus to a “text field” needs to be provided when the text field is selected to ensure that the focus has been moved into the “text field”
  • Need to ensure that all popovers and error messages could be closed by buttons and can be accessible by screen reader
  • All clickable objects need to be large enough to be tapped
  • Alternate options for device manipulation gestures like shake/tilt are provided using touch and keyboard options should be provided.


  • Consistent and simple layout for user interface needs to be provided and it will need to support both portrait and landscape mode
  • Key elements need to be displayed at the top before scrolling starts
  • Providing clear indication for actionable elements and getting confirmation from user when any major action  is taken
  • Grouping of operable elements that will be performing the same action helps in improving the touch area and will also provide better experience for screen reader based users
  • Provide error identification and suggestion by providing details of what data is incorrect and how user can fix it
  • Aiding input assistance by use of proper labels or instructions
  • Error prevention needs to be done by providing option to user for checking and confirming the data before submitting the content


  • Touchscreen devices need to allow external physical keyboards to provide user inputs
  • Minimize use of text field inputs by using selection lists; pickers, populating default values etc.
  • Setting the virtual keyboard to display based on the type of data that needs to be entered. Enabling numeric keypad, if numeric data needs to be entered is an e.g.

Accessibility considerations during development

Application content can be delivered to mobile devices on different formats:  Native apps, hybrid apps or mobile websites. Irrespective of the format, mobile applications need to make sure that accessibility features like VoiceOver, Zoom, Dynamic Fonts etc. are supported by default. Another pain point that needs to be kept in mind is the need for keyboard-based navigation, touch area size, proper color contrasts and maintaining proper focus order.

In native app development, accessibility APIs (application program interfaces) are available as part of development environment. This could be used either via the user interface or via the code. Setting accessibilityLabel values in iOS or setting contentDescription in Android will make the control visible to the screen readers.

For hybrid apps / mobile websites, screen reader / keyboard accessibility could be enabled by using the HTML5 and WAI-ARIA v1.1 Accessibility APIs. Some of the key points to note are:

  • Usage of alt-tag
  • Usage of caption and scope tags for tables will help screen readers to read the content properly
  • Usage of titles for web pages
  • Usage of default HTML Controls instead of creating custom controls

Lint tools are also available for native, hybrid and web applications to generate warnings for source code containing accessibility issues.

Accessibility testing

Development and testing teams will be able to verify accessibility features using Accessibility Inspector in iOS and Accessibility scanner in Android.

Website Accessibility could be checked using following tools.

  • A11Y Compliance Platform by Bureau of Internet Accessibility
  • Chrome DevTools by Google

Is digital accessibility a legal requirement for mobile apps?
Mobile Apps are generally covered by the same requirements for access by people with disabilities that apply to non-mobile software and web applications. U.S. laws that deal with accessibility are mainly Americans with Disabilities Act (ADA), 21st Century Communications and Video Accessibility Act (CVAA), Section 508 etc. Other laws like Equality Act in the United Kingdom, Web and Mobile Accessibility Directive in European Union, Disability Discrimination Act in Australia also gets applied for doing business in those regions.

The U.S. Department of Justice (DOJ) considers that ADA applies to public websites and other forms of digital businesses also. In disability access litigations, WCAG 2.0 Level AA accessibility conformance is required for companies that entered settlement agreements with the U.S. Department of Justice. CVAA standard needs to be followed if the application deals with text messaging, e-mail, instant messaging, and video communication or showing video program online that was shown on TV. Section 508 gets applied if the apps are procured by the U.S. government for direct use by Federal employees or used as part of a Federally staffed contract or for the public.


Enabling accessibility features for web and mobile applications not only benefits the persons with disabilities but also helps in improving overall usability of the application to all users along with helping the organizations in fulfilling legal responsibility, building corporate image and widening customer base. So, it is necessary for organizations and developers to understand the accessibility requirements and support in implementing it.

Looking forward for your comments.

Author Details

Navin Narayan

Navin is a Senior Technology Architect with Digital Experience unit of Infosys and has worked in mobility and cloud technologies across multiple domains. Navin has co-authored a book on Enterprise mobility and has US patent on mobile application space.

Leave a Comment

Your email address will not be published.