As UX designers, we always focus on what’s best for Mobile App users. But sometimes we forget that our products should be accessible to ALL our users. Our Head of Design, Damien, explains how to embrace accessibility with open arms.
Recently I've been championing accessibility within the Sugar Rush team. From previous digital transformation projects, when designing and developing Mobile Apps, I've learn't a huge amount on the best ways to approach building a product to meet accessibility guidelines. The important thing to remember is achieving accessibility isn't exactly as straightforward as compliant or not compliant. There are various shades of grey in terms of meeting compliance and when a product is live it's also really important that you continually check and re-check your product to see if code or content changes might cause issues.
But first, let's remind ourselves why we need to do any of this in the first place....
Why does accessibility matter?
– There are important legal, moral and business reasons.
– Accessibility matters NOT only for disabled people, but for everyone.
At some point in your life you will experience an impairment
Be it as several as a chronic illness, a broken arm or even as simple as trying to order a taxi with one hand whilst carrying bags of shopping. We all will experience impairment when using a product. The later example is referred to as situational or temporary impairment.
When users aren't able to complete a task easily they get frustrated, they don't blame their impairment, they blame the product they're using for not being able to accommodate for it!
What do you mean by Impairment?
So there are 4 types of impairment:
– Perceivable (Vision and Hearing)
– Operable (Motor or Movement)
– Understandable (Cognitive)
– Robust (The limitations of the platform or device that users are on)
Situational Impairment
As mentioned above situational impairment, here are some examples:
– Sunny day/noisy environment (Vision and Hearing)
– One-handed/injury (Motor or Movement)
– Fatigued/hungover (Cognitive)
– Out-of-date browser (Robustness)
So, now we know what impairment is, what codes are there to work to for it?
Getting up to code!
The benchmark for all accessibility is meeting WCAG 2.0 Compliance:
– AA (What most large companies strive for: Google, Apple etc.)
– AAA (gov.uk, charities etc.)
Accessibility can actually save you money!
– Legal Costly lawsuits for companies who are not up to scratch
– Win Bigger Contracts If we’re proven to build robust compliant systems
– Accessible for all! If your product is easy for impaired users, it’s even easier for un-impaired users!
– Better accessibility means better usability! Accessible apps return better engagement/conversion rates across the board
Testing for Accessibility
There are a number of tools out there to help you build accessible products.
Screenreaders:
– TalkBack Android’s built-in screen reader
– VoiceOver Apple’s built-in screen reader
– Chromebox Chrome Extension
– JAWS Desktop PC
Browser-Based Testing:
– WAVE Test any webpage for WCAG Compliance
– PopeTech Tests entire websites based on WAVE technology
Keyboard Testing:
– Navigating a website via Keyboard will help flag issues not seen in automated testing.
– Try tabbing through a website, see if you fully and EASILY navigate through all the content.
– It’s all about focus states and avoiding keyboard traps.
Human Testing:
– Human testing is more effective for finding specific issues and sense-checking the automated stuff.
– Using their own devices and setup.
It’s not a tick-box exercise...
Remember... It's not a simple tick-box exercise. When you've made your website or app accessible, a single update or CMS change can invalidate an entire system.
It’s a continued process of testing/re-testing... I'm afraid!
