We want to make our app accessible!

I googled around “Accessibility for app” and a lot of websites were quite airy fairy. Like yes you should do it bla bla— but no nitty gritty details.

Until I found the BBC website: https://www.bbc.co.uk/guidelines/futuremedia/accessibility/mobile/user-experience

I thought “great!!!”

Screenshot of the BBC website how they show examples of IOS and Android

So I set up a meeting with the team and showed them this website and what it might entail:

But app accessibility is new for us and still have a lot of questions, so the devs went away to do a tech spike.

What we found out was from the tech spike

  1. Pinch to zoom wasn’t standard for apps
    Besides google maps, we played around on other apps and couldn’t do it. It’s more of a web function. Android found a plugin that could do it, but clunky.
  2. Way more accessibility functions
    There was a lot more than what the website considered such as Switch control.
  3. A lot are baked into the phone
    Which meant for some functions like Magnifier — it requires no extra development work.

So…which ones do we choose?

Which function benefits exactly which disability/disabilities?

So I went back to good old Google to understand disabilities in Australia.

Surprising thing I found out:

  1. I didn’t know there was a psychiatric disability which includes anxiety and depression.
  2. I didn’t consider DeafBlind (dual sensory) — I only thought of hearing impairment and vision impairment on its own, didn’t occur to me you can have both.
The different disabilities in Australia and their descriptions ( I left out ones that wouldn’t apply to our app such as development disorders for children 1–5 years)
The stats I found online to each of the disabilities out of 22 million Australians. And yup, i spelt accessibility wrong :(

The Android and IOS devs tried to map out which functionality would benefit which disability section.

We had a big question mark for psychiatric
Mapping out which function is android/IOS specific and which disability it might cater for

Ok, we know the ideal state, but what is achievable?

But we still need to understand the sizing of each of these, which might help us inform which ones to start off first. (High accessibility impact if it affects more users with a lower tech feasibility).

I hate to say it, but like the “MVP of accessibility”.

On the top of our heads, we knew making the app work in landscape mode would be aloooot of work.

This is when things got a bit tricky.

Some said, lets leave it to the business to decide if they want to incorporate accessibility because its going to be a lot of story points.

Oh no! We should push this as a team to do it, even if its one feature or it would be pushed back and never be built.

Let’s be honest, it’s hard to explain the business value of adding accessibility in $ terms compared to a shiny new feature on the app that could rake in $$$.

Asking a for help

We asked a contact what accessibility traits they worked on first for the website here, and if they can give any guidance.

He also has contacts to the ABC app team who have an accessible app, and if we compile some questions would be happy to shoot them through.

Our ‘some’ questions turned into more of a list…

Trello board of a list of questions to the ABC team

Surprisingly it was very few dev or technically questions, as they usually google the code/answers themselves.

“Is the stats for accessibility in the app comparable to the stats found for disability in Australia?”

“What accessibility functions are used the most in your app?”

Meeting with Accessibility OZ

We didn’t end up meeting with ABC, but we were lucky enough to have a meeting with accessibility OZ instead and they presented a powerpoint deck:

Theres no accessibility in WCAG3 related to native mobile

Some requirements do, like colour contrast, but it doesn’t matter if its native mobile or not.

WCAG2 has stuff for mobile, like sites be accessible by keyboard, but doesn’t specify for native — i.e. touchscreen users.

WCAG2.1 has more for touchscreen users like pointer gestures and sensors, but still missing a lot for native mobile accessibility.

But some extra things I learnt:

  • Recommending native functionality including keyboards
  • Wary of using grey text even the colour contrast is acceptable, as users get confused if it is inactive/disabled content.
  • Underline all text links, some users won’t be able to tell colour difference
  • Capitalisation of words — it gets read out funny
  • PDFs aren’t good — you can’t apply any accessibility functionality on it (text resize etc)

The presentation was packed full of examples of fails, but it didn’t really answer our questions on scope and practically applying them in an agile/dev team. So I asked:

“So out of all the examples, what are the top two mandatory accessibility traits we should implement?”

Her answer:

“Every mobile accessibility specialist will have a different answer to that, but her top two are: use standard native elements and make sure everything has labels.”

Our MVP for accessibility

So as a team we discussed what is doable, low hanging fruit, what is non-negotiable and we came up with:

  1. Using standard elements — currently we have custom input fields, calendar and keypad for the login pin.
  2. Label everything — we had a seperate meeting to figure out how to implement this — deciding our BA will write it in the stories with the label text that devs can copy and paste into their work.
  3. Making all text black — working with the UI designer, agreed to keep the grey text, but set a rule if its grey text, the minimum size is 15. Give and take, compromise :)
  4. Support larger font size — large piece of work! Deciding to set a font-size to a maximum, and having difficulty on our text on cards.
  5. Making all text links underline — ran into some problems if a link is within or end of sentence of text, as it was hard to just put a touch target size area on it. A dev suggested to make the whole paragraph tappable for the link — but then we run into problems of the sentence being read out as a ‘button’.
  6. Magnifier and zoom/general display enlargement — no work for devs, but a lot of work with our tester.
  7. Providing a reason why link or button is disabled

Would have loved to add landscape functionality — useful for especially physical disabilities but the scope was too big.

Our first sprint is coming up with the devs implementing the above for the login screens so it’ll be exciting to see how it works!

Sydney based UX Designer who plays with code. I crack open ideas as a living!