While getting the lay of the land in Perth recently, I attended the Perth Web Accessibility and Inclusive Design breakfast meet-up, having previously attended the equivalent event in Sydney a couple of years ago.
This particular meeting was being led by Dr Vivienne Conway, from Webkey IT. Vivienne covered a lot of ground as she talked about her work in the sector, her role and experiences with W3C, as well as some insights on recent trends and emerging issues.
One of the cool developments she brought to my attention is evoGraphs, a jQuery plugin for producing screen-reader friendly graphs (pie, column, and bar charts). See the demo on YouTube:
EvoXLabs, as part of their “Project WhiteCane“, have also developed a plugin for providing multiple font options to website visitors. It’s great to see people giving up their time to make the web more accessible.
(Vivienne’s business card feature a clear adhesive braille sticker on the back. Another smart idea, and you can get your own by contacting Pia.)
Compliance or Conformance?
It was interesting to hear how governments around the world are working towards an accessible web. In Australia, and in the USA, accessibility is measured more through “compliance” statements, i.e. checklists. In the UK it is more about conformance, through real usability testing and evaluating the overall experience.
I’ve long tried to push this idea of conformance over compliance, but it is not an easy argument to win. Many organisations simply want a stamp of approval on their website, and rarely understand the ongoing work required beyond that single point-in-time. I see the idea of a website (and its component parts) being accessible as more than simply a checkbox process, but one also open to evaluation of intent and interpretation. You still need skilled individuals to make that judgement, but the four principles of WCAG 2.0 allow you to solve problems in multiple ways.
Accessibility as part of the process
I asked about opportunities or examples of accessibility experts working as part of iterative (Agile) web development teams, as opposed to accessibility testing done only at one or two key points (often very late-stage).
Webkey IT offer “partner plans”, by which their customers can buy an allocation of hours to call on. I think this is a good idea, but would like to learn more about development teams that are integrating accessibility into their sprints, and/or the team’s skillsets.
I often perform this role from an interaction design and education/advocate perspective, but I don’t have the unique qualifications that someone like Vivienne is able to offer. It is likely a combination of in-team skills, and regularly scheduled expert reviews that will provide the right balance for organisations and the users of their services.
It’s an early start to the day, but highly valuable insights gained. I look forward to the next one.