What Makes a Good Web Accessibility Guide for the Business?

by Destry Wion  ::  published 2 April 07    

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?

Latest Ten Articles

  • Finally Pro-MacBooked 6 April 07

    Six months later than expected, and on the eve of the new Apple Leopards, I am nevertheless a happy owner of the MacBook Pro, and it feels good.

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

  • Main Points Delivered at the First European eAccessibility Forum14 March 07

    I’m not exactly punctual on this one, but making a long story short, here are the main points as I took them from the eAccessibility Forum held in Paris nearly 6 weeks ago…already.

  • In Paris for the First European eAccessibility Forum27 January 07

    It’s going to be a whirlwind trip on the train, but should be interesting nonetheless.

  • Lose Readers by Moving Themes?14 January 07

    We hear about free Weblog themes all the time, and see the same ones all over the Web, but it’s not often you read about someone moving a personal theme from one self-owned domain to another, or the implications of doing so.

  • Book Reviews Coming to Wion18 November 06

    Reading and writing is my kind of chocolate, and when it comes to book reviews, everybody wins. I hope you’ll find them helpful. Stay tuned.

  • A Core Textpattern Technique Addressing Internationalization Interests14 November 06

    This article presents a core Txp technique for managing internationalization efforts, and three methods of use are described: 1) multilingual publishing within site, 2) collaborative international publishing between individuals, and 3) an alternate approach to #2 that essentially takes a community slant.

  • Textpattern Building Block Mechanics30 May 06

    Here is the second article in a two-article series about Textpattern building blocks. If you missed the first article, Understanding Textpattern Building Blocks, you might check it out too.

  • Heatmap Presentation of Eye-tracking Data17 May 06

    Isotopic heatmaps of eye-tracking sessions are easier too see and understand; hence, great slide material for stakeholder presentations (management, clients, and so forth).

  • IE Conditional Comments: Where Have They Been?19 April 06

    Conditional comments have been with us for years and largely unknown, but with the coming of IE 7 they may be the swan song that’s about to go platinum.