Accessibility 2.0 – A million flowers bloom

Last Tuesday, 2009-09-22, I attended AbilityNet’s Accessibility 2.0 conference at Microsoft’s London Victoria offices. Here is my writeup of the notes I took in a mostly unedited form. I hope you can make some sense of it!

You can get the speakers presentations as they become available from AbilityNet.

Greg Fields (RIM) – Designing Accessible Mobile User Interfaces

  • Use native UI components where possible.
  • Be mindful of colour and contrast; minimum 7:1 contrast.
  • Respect user preferences by inheriting global settings.
  • Error messages should help users recover from the error.
  • Context menus should have the most frequently used option as the initial focus.
  • Consistent navigation, controls, interactions throughout the application.
  • Progressive disclosure: make users aware of the number of step in a process.
  • Organise information by type, meaning, etc.
  • Limit ‘chunks’ of info to 3 to 5 items.

Christian Heilmann (Yahoo!) – Neither Technology Nor Accessibility Is Dark Magic

  • Accessibility movement does not have impact / momentum.
  • Social web can be user to spread the message.
  • WiiHab – technology making a difference.
  • Web 2.0 is for everyone, not just geeks.
  • Branding holds us back, acknowledge and work with the competition.
  • Make links understandable and predictable.
  • Knowledge + Passion = Accessibility.
  • Teaching means being open.

Access Beyond the Desktop

A panel consisting of:

  • Lucy Dodd (BBC)
  • Henny Swan (Opera)
  • Veronika Jermolina (AbilityNet)
  • Greg Fields (RIM)
  • Damon Rose (BBC Ouch)
  • Julian Harty (Google)

Greg Fields

  • Moblie surpasses landline in some markets.
  • Serverside speech recognition can work with fewer client side requirements.

Henny Swan

  • Concerned about making the same mistakes as on the desktop in 1998.
  • Crossover between mobile and desktop accessibility.
  • WAI-ARIA, CSS3, media queries, HTML5 and geolocation technologies need to be ported to mobile.
  • Progressive enhancement for mobile.

Damon Rose

  • Mobile is a ‘killer app’ for blind people.
  • Mobile sites must not destroy the web experience.


  • Same site with mobile stylesheet.
  • Allow personalisation and port preferences or allow different preference profiles for desktop and mobile.
  • Mobile accessibility requires collaboration between hardware vendors, software vendors and site / application developers.

Lisa Herrod (Scenario Seven) – Understanding Deafness: History Language and the Web

  • 1 in 7 (about 9 million) are deaf ro hard of hearing in the UK.
  • Big ‘D’ Deaf: culturally deaf, may not speak English as a first language.
  • Little ‘d’ deaf: does not identify with the deaf community, English as first language.

Steve Faulkner (Paciello Group) – Accessibility with HTML5 and WAI-ARIA

  • HTML5 semantic elements and WAI-ARIA landmark roles do not serve the same purpose.
  • Some HTML5 enhancements can be implemented with ARIA now e.g. HTML5 ‘required’ attribute is equivalent to aria-required=”true” attribute.
  • Canvas accessibility has fail! Bolt on not built in.
  • Audio, video and canvas fallback content should be outside the element – ignore the specification advice.

Mark Boulton (Mark Boulton Design) – Inclusive Design

  • Accessibility ‘experts’ need to educate designers better.
  • Accessibility is put off as ‘someone else’s problem‘.

Saqib Shaikh (Microsoft) – Silverlight Accessibility

  • Same accessibility challenges and requirements as any other development – colour contrast, semantics, etc.
  • Detects high contrast and operating system colours.
  • Works with browser zoom.
  • Controls are ‘lookless’ – their function is separate to their appearance.

To Comply Or Not To Comply

A panel consisting of:

  • Kath Moonan (AbilityNet)
  • Bim Egan (RNIB)
  • Léonie Watson (Nomensa)
  • Mark Boulton
  • Lisa Herrod (Scenario Seven)
  • Christain Heilmann (Yahoo!)


  • Accessible products can still have beautiful design.
  • Guidelines are a starting point not the end, and shouldn’t stop innovation.
  • Responsibility for accessibility should not just lie with developers.
  • Test early, test often, with as diverse a group of users as possible, with and without disabilities.


This was yet another great day for accessibility learning in the UK, following on from Techshare the previous week and Standards.Next at the weekend. Every presentation had something to say, and as usual it was good to get a chance to talk with like minded individuals throughout the day.

The day brought up a lot of discussion over how best to create mobile sites: same markup with a mobile stylesheet or a separate implementation based on the same content source. This is not my area of expertise, but I find it an interesting question nonetheless. I’m looking forward to hearing more on this.

There is one point I would like to comment on. Mark Boulton said that the current crop of accessibility experts, who in the main are developers, need to do more to educate designers. Kath Moonan said that developers were heroes for being the ones to learn the skills needed, and it was also said that developers should not be the only ones with whom responsibility for accessibility lies.

At the moment developers are expected to know about accessibility not just when it comes to the code they produce, but also in terms of design and content, which they are not necessarily involved in producing. While I agree that developers can help designers catch up this can’t last. Developers cannot continue to be the single point through which accessibility is researched and knowledge distributed.

It seems to me that designers need to not only take responsibility for the accessibility of their work but also for their own education. Those of us who have been thinking about such things for longer can start the ball rolling, but beyond that we should be working towards developers and designers having a basic but broad knowledge of accessibility on top of which each group builds its own specialist knowledge.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.