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!!!”
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
- 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.
- Way more accessibility functions
There was a lot more than what the website considered such as Switch control.
- 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:
- I didn’t know there was a psychiatric disability which includes anxiety and depression.
- 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 Android and IOS devs tried to map out which functionality would benefit which disability section.
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…
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?”
“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:
- Using standard elements — currently we have custom input fields, calendar and keypad for the login pin.
- 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.
- 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 :)
- 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.
- 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’.
- Magnifier and zoom/general display enlargement — no work for devs, but a lot of work with our tester.
- 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.