Establishing a mobile accessibility strategy can be a bit daunting. It’s tough to know where to start and even tougher to know where to stop: what devices should be supported, browsers, apps, access technology, who is it for and how teams can incorporate best practices into their working practices?
The goal is to make the web both portable and accessible but it’s a challenge marrying the ideal with the realistic in the vast, agile and diverse space that is ‘mobile’. Here’s a handful of some of the issues that have come up for discussion when developing portable, accessible content and how they are helping me shape a mobile accessibility strategy I’ve been working on. Needless to say this is very much a work in progress…
Who mobile accessibility is for
- Types of devices- touchscreen, keypad, tablet, flip…
- Operating systems – Windows, Symbian, iOS, Blackberry, Android…
- Browsers – mobile Safari, Opera Mobile/Mini, Fennic, Nokia…
- Native accessibility support – Voiceover (iOS), zoom, black on white, rotors, voice input…
- Third party assistive technology – Talks voice output, Talkback, Orator…
While mobile accessibility is all of the above for the purposes of this blog post, mobile accessibility is making web content accessible to people with disabilities in the mobile context. This includes users with visual, mobility, hearing and cognitive impairments as well as older users.
What devices to support
When developing on desktop we need to take into account 5 major browsers (Chrome, FireFox, Internet Explorer, Opera and Safari) and 3 operating systems (Apple, Linux and Windows). While this can be painful it’s not nearly as daunting as the mobile context where we have many, many more browsers and operating systems not to mention handsets (that can impact on how well styles are supported) and screen sizes. The mobile market is also more unsettled and subject to change as new releases come onto the market all the time.
It can be incredibly hard to know where to start and what devices to support. The harsh reality is you can’t build, test and deploy to every device out there guaranteeing a fully accessible experience. There are simply too many variables and too many unknowns.
So how do you decide what devices to support?
- Market share
As always it’s down to bums on seats. Statcounter generates statistics on mobile browser usage both worldwide and locally. Determining the popularity of devices for your target market provides a good starting point that can then be distilled.
- Existing supported devices
It may be that your organisation already has a list of supported devices. If that’s the case then from that list work out what devices have built in accessibility support – iPhone has VoiceOver for example – or what devices allow third party assistive technologies to be installed – Nokia and Talks for example.
- Research what your users are using
Probably the most important part of the process, and the most overlooked, is asking your users what mobile browsers they use. You can also look at your web traffic and see what mobile browsers and platforms are being pointed at your content. Anecdotal research such as the WebAim screen reader surveys also produce some interesting insight into mobile usage by screen reader users.
- Graded mobile browser support
- Devices with built in accessibility support
Devices with built in accessibility support – such as VoiceOver on Apple products, or the ability to zoom, select colour settings – are all obvious candidates to make the list.
If your organisation is already releasing apps on various devices as well as delivering general mobile content these apps should also be included in the strategy.
Running through the above check list I found the following themes:
- Most of our users were using iOS and Nokia devices
- Android lacked a robust accessibility API (to hook in voice output) but has useful accessibility settings
- Tablets were gaining in popularity
While we compiled a list of devices we decided the requirement should be to build and test against a set of general mobile accessibility guidance and develop device specific guidance. By integrating this into our development process we hope to widen the support considerably beyond our list of supported devices even if we initially test on only a few.
Mobile accessibility guidelines
There is no formal equivalent of the Web Content accessibility Guidelines (WCAG) for mobile however there are general Mobile Web Best Practices Guidelines (MWBP). Given the mobile context is inherently disabling there is is a significant cross over between the two, so much so there is a mapping between WCAG and MWBP.
This is a good place to start however it’s not practical to refer developers, content editors, interaction designers and testers to two documents that cross reference each other. What’s more there are also device specific guidelines which reference accessibility (for example Apple, Android, Nokia and Blackberry) all of which are relevant but taken as a whole not easily digestible or practical.
So what is the best strategy?
How general mobile guidelines are presented is a million dollar question but I prefer to break them down according to roles within a team:
- Devices (separate device specific guidelines)
There is of course a cross over between roles but the ultimate responsibility has to stop somewhere. Go on, be brave.
One set of guidelines for web and mobile with device specific techniques
The idea of agnostic guidelines is possibly a little over simplistic in a wolrd where we have to contend with websites and web apps as well as platforms and devices but I can’t help coming back to the knowledge that the principles of designing for the mobile web have a lot in common with designing for the desktop web and are, most importantly, shared.
- One web
- Progressive enhancement
- Graceful degradation
- Responsive design
- Web standards support
Time will tell as to what approach is best but the key is being realistic in what platforms/ devices you can support, understanding your users and supporting your development teams.
Having teams communicate with one another is also essential. Just because you have separate teams working on desktop content, Android and iPad apps it doesn’t mean they can’t share the same content strategy. Details such as using consistent text alternatives across desktop and mobile cut down development time and vastly improve the user experience when accessing the same content from desktop, phone and tablet.
I’d be interested to hear from anyone else going through the same process or if you have any thoughts on if there should be a base set of accessibility guidelines for all web content or not.