A is for accessibility

April 27, 2015

Author: Arq Group



Accessibility is becoming increasingly important in the digital space. With the reach of digital products extending millions of people all around the world, organisations have a responsibility in making their products accessible and easy to use. Outware Mobile’s vision is to create intuitive, effective and engaging mobile experiences that make a difference by helping people get things done, be more productive, learn, grow and be entertained. We believe that mobile technology is an enabler, and accessibility is critical to achieving this vision.

What is accessibility?

Accessibility for digital products means making them available and friendly for people with temporary, permanent or increasing disabilities. People with visual, auditory, physical, speech, cognitive, and neurological disabilities should have the opportunity to access and use digital products, and also contribute to them, the same as everyone else.

For those of us who work in the digital industry, this means that we have several factors to consider in design, development and testing to ensure that we create a product that everyone can use.

Increasing the accessibility in a digital product doesn’t just benefit those that have disabilities, it also helps people on slow internet connections, those who are ageing, and those on mobile devices. For example, drop-down menus are notoriously difficult to use on mobile, and are very difficult to use for those with disabilities due to their temporary nature (i.e. the drop-down menu when exposed stays in a temporary state – it is not permanently on show).

The global standard for accessibility

The Web Accessibility Initiative (WAI), run by the World Wide Web Consortium (W3C), have created accessibility guidelines which are used globally for desktop and mobile websites. These guidelines outline the different considerations that need to be made for all user interface (UI) elements on a screen, and how these could be made accessible.

In 2009, the Australian Government agreed to raise the level of accessibility of government websites, complying with an A level by the end of 2012. Some states committed to reaching a AA level by the end of 2014.

Unfortunately, there are no official W3C guidelines for implementing accessibility in native mobile apps. Native apps use UI controls and elements that are specific to the device and operating system (iOS/Android/Windows). The existing guidelines include non-mobile app elements, such as HTML, web technologies, and server side implementations, to name a few.

Our work on the RentRight app for Consumer Affairs Victoria addresses this gap.

Case study: RentRight app by Consumer Affairs Victoria


We were approached by Consumer Affairs Victoria to work on the second version of their RentRight app, which included a refresh of the user interface, and the addition of a number of new features. We were also asked to make the app compliant with the AA standard of accessibility.

Having discovered that there were no official W3C guidelines for implementing accessibility in native mobile apps, we adapted the Web Content Accessibility Guidelines (WCAG) for web and mobile web.

In order to derive comprehensible Mobile Application Accessibility Guidelines (MAAG) from the WCAG, we assessed every recommendation for its applicability to mobile. We analysed its meaning in the context of a mobile app and a mobile operating system, and how it could be met to either produce the same or better results as the results produced by the WCAG for the context of a web page.

We produced a new description to re-formulate the recommendation for the MAAG. Then we assessed if the operating system provided functionality to meet the recommendation or if further considerations needed to be taken. Those could be in the user experience design, in visual design, or during implementation. We then created comprehensive guidelines for each platform on how to meet the criteria of each recommendation which could be followed throughout the process and used as a checklist when reviewing our work.

We had a look at the native accessibility features that are available as part of the Android and iOS platforms. iOS and Android devices do support accessibility, including features such as increasing font sizes, inverting colours, using voice-over, and switch controls. However, there are still considerations we need to make when designing and building the app, to make it as friendly and accessible as we can.

Some of the WCAG recommendations simply do not apply to mobile apps. We did not just disregard them though. Instead, we chose to either incorporate the recommendation into the MAAG as non-applicable and explicitly explain why it does not apply and has no impact on any mobile application, or we could find an intention behind the recommendation that does apply in some form to mobile apps and would derive a recommendation on that basis rather than finding a mere translation from web to native mobile.

When following the platform implementation guidelines, many of the accessibility requirements are provided by the Android and iOS operating systems. Other requirements need to be considered right from the start of designing the application and are carried through from concepts to visuals to implementation, before being tested against the original MAAG.

Design: User experience, business analysis, visual design

During the design phase, we went over the adapted guidelines to ensure we addressed every point that applied to our app. Not everything applied, such as the accessibility requirements for videos, since we didn’t have videos in the app. Several important things we considered included:

  • Form fields: It’s important to keep labels on form fields persistent, and not hiding them depending on state (i.e. whether data has been filled in or not). In many apps, you’ll see labels on the fields in a form used as ‘hint text’, and when you start typing in data, the labels get hidden. If you were in accessibility mode using voice-over, and wanted to hear the field labels and entry after completing the form and prior to submission, the labels wouldn’t be read out if they were hidden, therefore providing less context to the data entry and increasing the chance of errors.


  • Error messaging: When validating the responses in a form, any errors that are produced should provide help and instruction to the user as to where the error has originated. Imagine filling out a long form only to hear that there is an error and you can’t proceed – but didn’t know where the error was! A way to solve this on a native app with accessibility in mind is to change the label of the field with the error – e.g. “Name” might change to “Name – error”, so when the label is read out, it is clear which field needs to be changed. Another way to do this is to visually signify the field, such as putting a line around the field. This can help those who don’t have voice-on and can still see visual cues.
  • Use of colours: We ensured that colours were not used as a distinguishing factor throughout the app, with all buttons containing words, or iconography used for actions in the action/navigation bar. Users did not have to distinguish, for example, between a green, red, or blue box on a screen in order to make a decision. Any links that were used to visit an external website were underlined and coloured in blue.


  • Voice-over copy: The voice-over copy was written to convey instructions on how to navigate and complete the screen, and describes the elements on the screen. This is particularly important for someone with vision impairments, and need to have the screen read out to them. As each label is read out, it is important that these are descriptive and not ambiguous. States can also be described, for example, a button might be or ‘button – dimmed’ when it is not tappable, or ‘button – active’ when the disabling is lifted.

Development: Android

Provided when you create your user interface you use system provided standard components, the Android platform requires only a few additional steps to make your applications accessible. Some of the additional measures we had to take to make RentRight accessible include:

  • Focus-based navigation: It was important to ensure that all user interface elements can be reached and interacted with via directional input methods (either hardware or software based). In unique instances, we were required to change the focus order in our user interface to be more logical for users, as well as potentially make components focusable to provided more context. This was achieved by applying the android:focusable, android:focusableInTouchMode and android:nextFocus XML layout attributes.
  • Describe user interface controls: We had to ensure that all user interface elements had descriptive text (which may have differed from what was displayed) to help provide the user context via voice-over. We had to pay special attention to visual components such as images and tabs. This was achieved by applying the android:contentDescription XML layout attribute.


Development: iOS

On iOS we took the full advantage of the native VoiceOver and UIAccessibility programming interface (available from iOS 3.0). The UIAccessibility protocol is implemented as a part of the standard UI controls. This ensures the the basic accessibility feature being available when we used native UIKit elements. As part of the development, we make sure that all the standard UI elements has the following attributes are set (where applicable as per MAAG) in RentRight:

  • Label
  • Traits
  • Hint

However, to comply with the MAAG on RentRight we needed to customise the accessibility behaviour on few standard elements such as segmented control. In addition to that we implemented the our own custom views that provides it’s own accessibility information for different states. For example, the area assessment screen in RentRight:


There are two ways to implement custom attribute information

Define custom accessibility information in Interface Builder (IB)

  • Define accessibility programmatically.
  • In RentRight we used the programmatic approach.

Following is an example code snippet providing attribute information in a custom subclass implementation:



Our main aim in testing was to ensure the following basic points for accessibility in the app:

  • Label: Every element in the application should have a meaningful label.
  • Hints/Language: Every element where a user needs to take an action should provide a meaningful and clear hint. Based on these hints, a user should be able to easily decide the flow in application.
  • Flow: The user flow on the screen should be from top to bottom and left to right. The flow throughout the app should be intuitive.
  • Display: The user should be able to zoom in, increase the font of the text in the application. Error messages should be clearly visible.
  • Focus: The user should be able to focus on every element on the screen.

To help achieve these, we decided to close our eyes, put on earphones and simply follow the hints and the text speech to navigate through the application. The reason behind this was if in case the label or hint was not clear to us after testing the app for a few months, then it would not be clear to new users.

For checking the display, the user should be able to zoom into different parts of the screen and even increase the font size. In this case, the text should not be truncated and the entire text should be read out.


Our experience on RentRight helped us create a set of accessibility guidelines specific to native iOS and Android applications, that can be re-used to assess and design other apps. Our goal is to help our clients understand the importance of accessibility and create mobile experiences that are intuitive and easy to use for all.

For more information on accessibility:

Download the app:

Apple_store_rent_right_app Google_rent_right_app


This article was written by:

  • Kelly Jennings, UX/BA
  • Frank Ziegler, Project Manager
  • Jonathan Causevski, Android Developer
  • Mahmudul Alam, iOS Developer
  • Meetu Singh, QA Analyst