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

The mobile context is by definition disabling. Mobile doesn’t lend itself to easy browsing when you’re on the move, dealing with poor light, glare, small screens, old hardware and small keyboards. As well as taking context into account developers also need to consider variable support for web technologies (HTML, CSS, JavaScript etc) within different mobile browsers and platforms. There are a daunting amount of variables that impact on how we access mobile content including:

  • 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?

  1. 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.
  2. 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.
  3. 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.
  4. Graded mobile browser support
    The jQuery guys have used the Yahoo! graded browser support model to develop their own graded mobile browser support for mobile. This is crucial as you can’t build accessible mobile content without knowing what the lowest common denominator phone your building for is. From this you will also be able to determine what technologies you use to build your site with: HTML 5, CSS 3, JavaScript, WAI ARIA and Flash as well as your baseline for colour, font and style support. Just as with desktop progressive enhancement and graceful degradation are key.
  5. 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.
  6. Apps
    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?

Establishing a set of core mobile accessibility guidelines internally is a good place to start. These should list all guidelines that are relevant to mobile content regardless of the platform or device with a baseline of technology support (HTML, CSS, JavaScript etc) decided in accordance with the least advanced device in your list of supported devices. These general guidelines can then be supplemented with device specific guidance where necessary.

How general mobile guidelines are presented is a million dollar question but I prefer to break them down according to roles within a team:

  • Design
  • Develop
  • Content
  • Interaction
  • 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

Writing a core set of mobile only accessibility guidelines is a lot of work and time will tell if in fact it is the best strategy. As previously mentioned there is also a significant overlap with WCAG. I think it’s a really, really useful process to go through but I’m simultaneously asking myself if we even need seperate mobile and desktop web accessibility guidelines. Surely a baseline shared set of guidelines could work? WCAG is after all ‘technology agnostic’ (i.e. HTML, CSS, JavaScript, Flash etc).  Could we take the same approach and have a core set of accessibility guidelines that are both technology and device agnostic?

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.