appsforall
appsforall_blog.jpg

Blog

Our recent blogs


What You SHOULD Do When Building an Accessible App

This blog is based on Kira Daley and Amir Ansari’s A11y Camp 2018 presentation ‘Dos and Don’ts When Building an Accessible App’.

We’ll be posting the second part of this blog - ‘What You SHOULDN’T Do When Building an Accessible App’ - next month.

Expectations vs. Reality

Many people in the product delivery space will be familiar with product sliders, which are used to determine how much attention certain features or functionality should get. At Transpire, we use them at the start of a project kickoff to define the customer's priorities from the get-go, ensuring every team member is on the same page.

To begin with, accessibility is just as important as things like scope, time and budget.

Product priority slider showing that accessibility is on par with things like scope, time and budget.

Product priority slider showing that accessibility is on par with things like scope, time and budget.

Unfortunately, accessibility can quickly fall to the wayside when the reality of things like time, and scope kicks in, and takes precedence.

Product priority slider showing that accessibility gets forgotten about.

Product priority slider showing that accessibility gets forgotten about.

A few years ago, Transpire made a clear commitment that accessibility would no longer be a line item or a consideration. It was unspoken and non-negotiable - simply something you would get when you chose to work with us.

Product priority slider showing that accessibility is a non-negotiable line item at Transpire.

Product priority slider showing that accessibility is a non-negotiable line item at Transpire.

We don't proclaim or promise to be the best accessibility experts in the digital space, but it is one of our core values that's always front of mind.

Create Your Minimum Accessible Level

Thankfully, with one of Transpire's most recent projects, releasing an accessible app was front of mind for the customer. This allowed the design team to create a bare minimum level of accessibility requirements during the project kickoff.
We refer to this as our accessibility acceptance criteria:

  • No autoplay/continuous motion - If there are moving images and graphics, the speed should be slow.

  • Touch targets -

    • 48x48 dp for Android

    • 44x44 pt for iOS

    • 8dp away from one another.

    • Must be labelled to allow for screen readers and assistive technology on all read parts of the interface.

  • Dynamic fonts/adjusting containers - Android is relatively straightforward because of the myriad of different devices out there. Apple has only recently started to adapt, requiring a lot of design conversations and considerations.

  • Image alt (alternate) text, and images and text should be grouped accordingly.

  • Colour contrast (checked with tools such as the Colour Contrast Analyser)  

    • Small text: at least 4.5:1 against its background

    • Large text (at 14 pt bold/18 pt regular and up): at least 3:1

    • Icons: at least 4.5:1 contrast

Test With a Wide Range of User Types

In order to validate our digital products regularly, we aim to test with users every sprint or every two weeks with five people (one at a time). Out of those five people, we always want one individual who is living with a vision, hearing or mobility impairment, has neuro-diversity or is blind, reflective of the 1 in 5 Australian’s who live with a disability.

Unfortunately, we've found that market research recruitment databases are lacking in people with accessibility needs. Even when we do find suitable people to test with, they aren't always aware or don't even use accessibility features.

As a result, we've learnt that we need to be very specific in our recruitment brief when working with market research requirement companies - sometimes even going as far as asking for people who use assistive technology. We enlist the help of Intopia Connect - a digital agency that promotes inclusive design and development - to help us find people who meet our brief.

In addition to building empathy across our team of developers, designers, testers, and product owners, this approach (testing with diverse people) has also uncovered a few 'aha' moments for ourselves.

For example, one of our assumptions was that people who used voiceover or talkback (iOS and Anroid’s text to speech functionality) when browsing content on the screen would be tapping on their screen or moving their finger around looking for words to be spoken. But in reality, we noticed that almost every single person who uses voiceover or talkback uses the left and right gestures to skip forward or back in content. This totally changed the way we thought about the screen and how we designed it.

Two iPhones with illustration of gestures.

Two iPhones with illustration of gestures.

Think of Accessibility at a Screen Level

It's all well and good making sure that you adhere to your baseline accessibility criteria. But if you aren't thinking about how an entire screen works and functions, you're going to run into issues.

When thinking about vision impaired and blind users, it's not enough to just design, label, and apply the right elements. You should also think carefully about how all of this information will be read out.

Just because you've got a well designed UI with everything labelled properly, doesn't mean to say that this automatically becomes a positive experience for blind or low vision users.

By grouping certain areas together to explain a screen's visual distinctions, you should be able to reduce complexity and anxiety while increasing comprehension and understanding.

Here’s how Transpire managed to remove screen reader confusion for Virgin Australia users by grouping areas differently to explain the visual distinction that is on the screen.

Virgin Australia app screen reader before change.

Part two of this blog - ‘What You SHOULDN’T Do When Building an Accessible App’ - will be published next month (June 2019).

Amir AnsariComment