What Makes a Good Web Accessibility Guide for the Business?

2 April 07

With pressure mounting on web developers and companies alike to provide quality eAccessibility products and services, it makes good business sense for companies to have their own eAccessibility guidelines to help ensure development objectives are being met in efficient and cost-effective ways. However, just knowing guidelines are needed is one thing, producing and integrating them into a development workflow is something else. What breadth and depth of information should they cover? How should they be written and structured for maximum understanding? What format provides the best utility? Seemingly, the preparation of eAccessibility guidelines is not a fundamental task, the considerations are many.

If you follow the forward-edge talk on eAccessibility — a term gaining a foothold in Europe that specifically implies accessibility in Information and Communication Technology (ICT) — you should be getting the sense that pressure is mounting on the web developer’s of the world to produce high-quality eAccessibility work. Despite developer cries that site owners should bear some of that responsibility (and perhaps rightfully so), they must bear the bulk of the burden since they, more than the clients they provide services for, are the expected experts on the topic, at least until accessibility specialists start taking their rightful place in the development team.

Taken further, if these developers work for a company that provides ICT services and products, then the responsibility transcends to the company as a whole since the company’s reputation and bottom line come into play. In response to this situation, companies are increasingly producing internal guidelines that help to ensure their development teams are being complete, compliant, and consistent in their eAccessibility efforts.

As it turns out, I have the charge of producing such a document (or series of documents as needed) for the web services department at my job, and it’s not as easy as you might think it to be. From the outset, the goal is to have a comprehensive guide that informs our staff about:

  • the importance of eAccessibility,
  • the applicable laws behind it (relevant to our geography),
  • the kinds of disabilities eAccessibility accounts for,
  • the existing references that support eAccessibility development,
  • the guidelines themselves (relevant and succinct yet sufficiently detailed)
  • and so forth.

Of course the guide will be based on the W3C/WAI‘s Web Content Accessibility Guidelines, yet modernized and targeted to our own workflow and products. Further, being we are in France our guidelines will map to both the French AccessiWeb criteria and the EU Web Accessibility Benchmarking Cluster’s Unified Web Evaluation Methodology (currently version 1.0).

The company guide I’m producing will also take into account methodology for developing and validating eAccessibility, which means specifying:

  • code techniques to use under particular circumstances,
  • tools to use that help automate testing,
  • baseline code and content elements to check in manual verifications,
  • and even protocols for real user testing.

Finally, at least as I see it at this early stage, there should be some materials that help with the validation and testing phases, such as check-off lists, comment grids, and/or whatever else might be identified as useful along the way.

To prepare for this project, I’ve begun a phase of research, which for the moment is to collect as many comprehensive agency/institution eAccessibility guides I can find that might lend insight to the structure and format of the guide I am producing. I think this is important because in addition to being thorough and relevant to our workflow and products, the guide must also be usable. In other words, the guide should not come across as an intimidating book, or a bland white paper on company policy, rather it needs to be easily read, direct, parsable, and cross-referenced without being hyperlinked to death.

Not surprisingly, there are not a whole lot of these guidelines to be found online, at least not to the level I am aiming to produce myself. Unfortunately, I won’t be contributing to that knowledge base either because the guide is mandated to be an internal company document, not distributed to the public.

So far I have only found the following to be of any particular use:

Of all these (and outside of the classic WCAG reference), Microsoft’s document is proving to be an excellent reference for considering how to structure such a guide, and particularly as it takes into account the AccessiWeb and UWEM protocols that we are also recognizing due to our geographical context.

I’m still looking around, but if anyone has other suggestions for guides to consider, please point them out.

Getting past the research phase, and once a first draft is prepared, the guide will be circulated to our project managers, Research and Development, and to our squad of front- and back-end developers for commenting. All feedback will be used to produce a second draft. The second draft will likely be a working prototype, which should iron-out more kinks when it’s actually in use, thereafter leading to a more finalized third revision. Of course such a document will never be static, but rather undergo periodic revisions in parallel to changes in industry tools, trends, and guiding references (such as the anticipated move to WCAG 2.0).

So, I’ve shared a few thoughts about the guide I’m working on, what do you think are important considerations, topics, and formats for such guides in general?