Outware Insights

Browse by category


Imagine using your favourite app with your eyes closed, slightly open or with no colour.

Would this:

  1. Frustrate you?
  2. Degrade your user experience?
  3. Limit you from using some features of the app?
  4. Make you feel like you’re missing out on something?

I’m tipping you answered yes to a few of the above points. For some people, this is a reality when using all apps. Luckily, with the tools we’ve got at our disposal today, we can somewhat solve or lessen these problems for accessibility users.



Mobile accessibility means making apps usable for everyone. Including those who need assistance with or are limited in:

  • Vision
  • Hearing
  • Physical movements (i.e. fine motor skills)
  • Learning and Literacy



Recently we’ve seen the mobile accessibility features for iOS & Android devices advance significantly. This is great because accessibility users can get closer to the action and enjoy features they otherwise wouldn’t be able to interact with.

Features that can enhance the in-app experience:

  • TalkBack (Android) & VoiceOver (iOS) – Also known as a screen reader, allows the device to read elements on the interface aloud
  • Speech rate
  • Inverting colours/grayscale
  • Large text
  • Bold text
  • Reduce motion
  • Increase/decrease contrast
  • Reduce transparency
  • Accessibility rotor (iOS) (See Figure 1)

Figure 1 – Using the rotor in iOS

Using the rotor in iOS



We’ve all painfully assembled that piece of furniture from IKEA. Don’t you hate that feeling when you get to the end of assembling your shiny new coffee table and you realise you’ve got 10 screws, 3 bolts and a piece of chipboard left over?

You open the instruction booklet and find that those components should’ve been assembled at the start. As a result you need to pull the table apart, insert the chipboard and put it all back together.

Sounds very similar to building accessibility at the end of a project!

The solution – build accessibility as you go! Ensure mobile accessibility requirements for a particular screen are covered in a user story that can be delivered in a single iteration. This will:

  • Avoid reverse engineering
  • Avoid unnecessary refactoring and rework
  • Promote a healthy codebase
  • Get it done faster
  • Trigger the right discussion early on – design for accessibility

Hot tip: Google have released a tool to scan for accessibility for Android devices, it can be used to get feedback on how your app compares to best practice.



Screen Reader (VoiceOver/Talkback)

  • The element in the top left hand corner should get the focus when the user first comes to a screen
  • As the user traverses through the screen swiping left/right the focus will shift from left to right, top to bottom of the screen in a zigzag pattern (See Figure 2).
  • Only read out what’s necessary, don’t give too much information
  • Always announce the screen title when the user navigates to a different part of the app
  • Use actions or verbs to describe elements (See Figure 3)
  • You can always add a hint to describe the element in more detail if it’s too complex to cover quickly

Figure 2: The Opal Travel home screen in iOS – elements labelled according to best practice announcement order

Example: Opal Travel Voice Over Order

Announcement order:

  1. Navigation Menu, Button
  2. Home, Heading
  3. Refresh Opal cards, Button
  4. List of Opal cards, swipe with three fingers to navigate your Opal cards. <read card detail>
  5. Top up, button
  6. Trip planner, button
  7. Opal activity button
  8. Last updated: <read updated info>


Figure 3 – An example of an action, not what the icon looks like. Source: Google Material Design Guidelines

Example: Actions to describe elements
Visual Design

  • Accessible colour palette – Choose primary, secondary, and accent colours for your app that support usability. Ensure sufficient colour contrast between elements so that users with low vision can see and use your app.
  • Visual cues – For users who are colourblind, or cannot see differences in colour, include design elements in addition to colour that ensure they receive the same amount of information. Eg: if a text field has an error state, don’t just underline it red. Provide some words in addition to the red content to describe the error. (See Figure 4)

Figure 4 – An example of a visual cue error state. Source: Google Material Design Guidelines

An example of a visual cue error state
Touch Targets

  • The area in which responds to the user’s input (button, fab, navigation item).
  • Ensure these targets aren’t too small and would challenge those with under developed fine motor skills.

Figure 5 – Example of button touch target (pink area).

Example of button touch target

  • When used properly can provide a next level experience alongside talkback/voiceover
  • Enables the user to interact with additional functionality not otherwise available or visible to them
  • Should only be used in specific scenarios eg: tap and hold to delete/double tap to select

Figure 6 -Gestures can be used with VoiceOver/Talkback to provide additional functionality to the user.

Image illustrating different gestures



If you need a device that will offer a variety of accessibility features, screen reader consistency and the ability for me to customise my experience, strongly consider Apple.

After recently working on a large accessibility piece for the Opal Travel app (NSW Government), my experience was that iOS had a superior offering to that of Android.

The main reasons for this opinion are:

  • The iOS range of accessibility features is more extensive
  • Quick access to customise accessibility tools using the rotor. This means the user can edit preferences without navigating to phone settings
  • More consistency across different OS versions and devices. Accessibility works a lot differently on Android devices due to the number of different manufacturers, hardware and OS versions

In saying this, I don’t think Google is too far off the mark and I’m sure it’ll be a tighter race in the near future.



  • It starts with design. In the early stages of a project, think about accessibility, have discussions, challenge opinions, design for accessibility users.
  • Think colour, button size, video placement, layout, menu interaction, onboarding tutorials, splash screens and how an accessibility user would interact.
  • Test your solution with potential users to validate output.
  • Poor accessibility may mean a loss in a segment of users and potentially some negative brand exposure or reviews in the Play Store/App Store.
  • The Google Material Guidelines for accessibility highlight some great tips when designing for accessibility – well worth a look.

Accessibility users expect that most apps support some kind of accessibility, which enables them to use an app just like any other user would.

Put yourself in their shoes, there’s no reason everyone can’t enjoy modern technology!

Recent Articles