Getting to grips with a mobile accessibility strategy

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.

13 thoughts on “Getting to grips with a mobile accessibility strategy

  1. It was great to see your timely post as I was working on a W3C widget a11y best practice guide for the RaveInContext project. I was pleased to see we have much the same ideas and view of the issues. I had forgotten Yahoo! Graded browser support so that for that.

    Anyway here’s the article and lets keep in contact about this (please feel free to update the article)

  2. .This got me thinking about the broader issue of making information available to the public should all government semi-state bodies be required to create mobile-friendly versions of their web sites? It seems clear that having mobile-friendly versions of government sites will make the information more freely available to more peoplenot everyone has a PC after all.

  3. Steve – this is a great resource, thanks for posting. I’m glad we’re thinking along the same lines too.

    Mr Owens, I think making sure your site is available across devices is key, yes. However don’t think you have to go making separate ‘mobile friendly’ versions. Step one is to ensure that your site follows web standards and is accessible. This will go a long way to ensuring it renders well on mobile. You can then optimise what you already have for mobile by incorporating responsive design, progressive enhancement and so on.

    Bruce Lawson has an excellent post on is mobile web development compatible with one web that’s well worth a read.

  4. Love the idea of ‘agnostic guidelines’ I’ve long argued that accessibility and usability are two sides of the same coin, ‘agnostic guidelines’ is a good covering concept.

  5. We’re going through the same thing at my organisation. Awareness of web accessibility is pretty high, but we’re really starting from scratch on accessibility for devices and we are beginning by looking at native support, plug-ins etc. We’re in the process of commissioning a set of guidelines that will focus in turn on different device types, e.g mobile, tablet, games console, and give us some tips on best practice, pitfalls to avoid, how to use the native support etc. It should all be very educational I hope!

  6. Nigel – usability and accessibility are two sides of one coin in one respect but by ‘agnostic guidelines’ I’m thinking more along the lines of technology agnostic rather than bundling usability and accessibility together (if I’m understanding you correctly).

    Take for example WCAG 2.0 Guidelines 1.1: “Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.”

    You could use the same advice to apply to iOS, Android, HTML and Flash (the last two already feature in the techniques). For Android and iOS you only need add in techniques specific to those platforms.

  7. Anne – it’s pretty daunting for an organisation of any size to but if your organisation already has a high level of awareness for accessibility then you’re in a really good position. I’m finding that in many respects it’s a case of joining the dots and reusing existing expertise, documentation and resources you have internally.

    One thing we’re finding helpful when writing device specific guidelines is to audit/review existing mobile sites and apps against existing accessibility standards (be it WCAG or organisation specific ones) then take those findings and feed them into the device specific guidelines being written. In doing that you can unearth a few ‘essentials’ to add to the requirements that aren’t in any existing accessibility guidance for devices. If you can get users involved in testing then all the better. Given mobile accessibility is so new user testing really is essential.

    I’m not sure what systems or processes you have in your organisation but using existing bug tracking systems and knowledge management systems is helpful. I use Jira heavily for raising tickets for bugs, feature requests and improvements, and the Intranet for support documentation. As an accessibility person you can be in a unique position to get involved across teams and centralise learnings from teams. Having a member of each team (web, iOS app, Android app, games consoles etc.) appointed as the accessibility contact and champion also helps build a horizontal network.

    I’d be interested to hear more about how it all goes and perhaps share notes.

  8. Pingback: Mobile Accessibility Guidelines | » Henny Swan's blog

  9. Pingback: 모바일 접근성 관련 주요 가이드라인 등 – Henny Swan 블로깅 의역을 중심으로 « 삐돌이의 웹 접근성 & IT Transformation

  10. Pingback: Grips Black | Carbzine Paintball

  11. Great to see you making available the thinking behind the work you’re doing on this at the BBC, Henny. And great to see your thinking building on what Judith Garman started looking at there years ago.

    I agree that device agnostic guidelines are definitely the way to go.

    The interesting thing in making these guidelines I guess is how you untangle WCAG 2.0 from some of its assumptions. Keyboard accessibility has always been a core part of accessibility, but assumes the device has a keyboard, which isn’t the case with touchscreen phones. Similarly, WCAG still assumes levels of accessibility support in the browser (which should comply with UAAG) which aren’t there in most mobile browsers – I’m thinking of being able to override style-sheets and increase font size as two obvious cases. And mobile apps make this even more difficult, as the level of accessibility support the browser usually provides is completely missing, leaving the developer only being supported by the accessibility features of the operating system or installed assistive technologies.

    On the other hand, there are also some really useful facilities now common on mobile phones which it might be useful to _start_ making assumptions about – such as GPS. The inclusion of location-specific services is already having a positive impact on the usability and accessibility of mobile apps and web, and it would be good to see this included in mobile accessibility guidelines. Mobile is a huge opportunity for disabled and elderly people, as well as currently being an accessibility challenge (see my slides on this at:

    So it seems like mobile is going to unpick all our assumptions, and then require us to reassemble something device and context agnostic. This wouldn’t be the first time, as WCAG 2.0 picked apart the assumption that everyone used HTML to allow other technologies to be covered. Maybe it’s time that process happened again for mobile…

  12. Pingback: Mobile accessibility presentation at CSUN 2012 | » Henny Swan's blog

  13. Pingback: Tips For Accessibility Testing Of iOS Apps | Pat's Tapestry

Comments are closed.