Accessibility on mobile: what do brands and developers need to do?
George Gabriel, 29 April 2014
Tagged with: Accessibility, android, apple, HTML5, mobile app development, Web
Smartphones can be invaluable for disabled users, but many apps are not accessible to all. So what needs to change? Advice from the UK’s leading charities is clear that the Equality Act and the Disability Discrimination Act apply to digital services, including apps. But this isn’t just about legislation or ethics; accessibility makes good business sense too.
The functionality to enable many disabled people to use smartphones is present in the operating systems, and users can customise their phones, selecting from a broad range of settings to meet their needs.
iOS allows visually impaired users to navigate via touch and voice (VoiceOver, Siri, Speak Selection and Dictation). It also lets users increase the font size, select different colour options – vital for those who are colour blind – and so on. In this short film a blind user explains how he uses an iPhone. Well worth watching.
FaceTime is useful for hearing-impaired people who prefer to communicate via sign language, and closed-captioning makes film and podcasts more accessible. In addition, smartphones can signal via haptic feedback.
There are settings that may help users with physical or motor challenges, and people who have trouble communicating, such as those on the autism spectrum, stroke sufferers, or people with other learning or communication difficulties. Apple’s accessibility page gives a fairly comprehensive overview. iOS is thought to have the edge in this area but Android and Windows Phone also offer many of these functions, and Android’s Talkback is the equivalent to VoiceOver.
There are lots of smartphone-related products on the market specifically for people with disabilities.
There are hardware peripherals such as hearing aids that utilise the phone’s microphone to zone in on a particular source of sound, and braille keyboards. More recently, wearables have encroached into this space and are beginning to prove particularly useful in the fields of healthcare, fitness and accessibility. But we’re focusing on mainstream apps, and what needs to be done to make them accessible to all.
What lessons can be learned from the Web?
The Web’s journey towards accessibility is relevant here. The WorldWideWeb Consortium (W3C) produced Web Content Accessibility Guidelines many years ago. The W3C has also produced Mobile Web Best Practices guidelines, but they are geared to HTML5. Websites should conform to British Standard BS8878, a code of practice for web accessibility. Its lead author says the principles are equally applicable to app development.
Where should we go for expert advice?
There are several bodies that work towards better digital accessibility. AbilityNet is a charity that provides app and website accessibility testing for brands. And OneVoice is a network for accessible ICT.
Most up-to-date – and possibly most useful – are the BBC’s Mobile Accessibility Guidelines.
And there is a 40-minute lecture on accessibility and UX by an iOS developer, aimed at technical people, here.
So what should developers do?
Most discussion is around visual impairments, but it is important to remember that there are many different kinds of disabilities that create different accessibility issues. OneVoice has a useful list of the different kinds of disabilities developers need to cater for, and it also lists the first seven steps towards accessible apps.
Another good primer is developer Matt Gemmell’s blog post about accessibility for visually impaired users of iPhone and iPad apps. Apple has referenced this blog post when communicating with developers about accessibility. As Gemmell says, it is useful to play around with the phone yourself to see what can be done. (On an iPhone go to: Settings/General/Accessibility.)
Once the importance of making apps accessible is grasped, the build should be fairly straightforward. Android and iOS give developers accessibility prompts throughout, though unfortunately the prompts are easy to ignore. It’s important for all members of the team to be on board as UX decisions like colour contrast can be of critical importance.
As such, it is essential to state the importance of accessibility principles at the outset, build them in to the development process and to test thoroughly at the end. Both Android and iOS have Accessibility Developer Guidelines and Checklists.
Who does it well?
In the past, Apple has recommended Science 360 for iPad, the NYTimes for iPhone, Shazam, Dictionary.com, Inkling and Urbanspoon. Among mainstream apps, AbilityNet recommends Waze and Skype. Transport for London runs awards for accessible travel apps, and last year’s winners were London’s Nearest Bus, Station Master, Tube Tracker and Colour Blind Tube Map.
AppleVis, a group for blind and low-vision users of Apple products, has an app Hall of Fame (which includes Twitter and Dropbox), monthly picks, and – take note – a Campaign of the Month that targets apps with accessibility issues. Some rather famous names there…
Future Platforms has an accessibility policy; we are working with our clients to ensure these standards are baked in from the start on new projects, and to update existing apps to make them as accessible as possible.
We are conscious that there are areas we will not have covered in this newsletter. Please get in touch with any suggestions. Content will be updated if appropriate.