Wanted to point folks to Karl Groves' article Do Accessibility Testing First, I really like his idea of automated nightly testing for accessibility. I also wanted to acknowledge that this is more of an accessibility evaluation tactic than methodology.

I just got word that the Web Accessibility Initiative's is starting up a WCAG 2.0 Evaluation Methodology Task Force to provide more comprehensive guidance on evaluating web accessibility.  This is great, not only because the Web Content Accessibility Guidelines (published in December 2008) aren't written for the average developer, but also because it should make it easier to build sites with fewer barriers for users. If the projected timelines are accurate, the first draft of the Evaluation Methodology will be developed at about the same time that all new Government of Ontario websites will need to be WCAG 2.0 AA compliant. It won't be 3 to 9 months after that however before the final drafts are available for public review.  

I have a lot of respect for the process of developing standards and know I don't have the patience for it.  I'd like to have the time to participate in the WAI Interest Group, but although the discussions are public and searchable, it isn't as easy to get involved as it is with the Drupal community where it is possible to follow specific issues over time. There are a lot of interesting people who have contributed a lot of time to shaping the W3C's standards, I do find that the focus is now too much on evaluating individual sites and not enough on leveraging the ecosystems that are used to build them. There also isn't enough discussion of free online tools that can do so much to improve a site's accessibility. 

Acknowledge What Already Exists

Most websites are built today with libraries of code that very much shape their accessibility.  Problems within a CMS or JavaScript library will affect the accessibility of the sites that use them. If the communities behind these projects are actively working for improved accessibility, many problems can be avoided.  We've made some great enhancements to Drupal 7's accessibility, and although it's true that each of those could be reverted in a particular site's implementation, it's unlikely that a developer would take the time to do this.  Evaluating a Drupal 7 site's accessibility should be fundamentally different than a custom built website, because the framework that is actively being reviewed for accessibility improvements.

The Perceivable, Operable Understandable & Robust (POUR) framework from WCAG 2.0 is great, but there needs to be greater emphasis on using simple tools like Holmes CSS which can alert website editors about simple accessibility problems. Surely a piece of text or image outlined in red is a stronger reminder to editors than a long WCAG checklist. There are so many great tools like the WAVE's Toolbar that are so good at catching stupid, extremely common accessibility mistakes. There is no automated tool that will be able to identify all accessibility barriers, but surely we can lean on a few to pick out the easy stuff.  

Just One Piece of the Puzzle

WCAG 2.0 is a set guidelines that need to be evaluated along with accessibility focus groups & user feedback. The guidelines do not stand on their own and the W3C has written up guidelines for involving users with a disability. There are so many different types of barriers for people with disabilities it is important to actively seek input from the disability community.  It should be clear from your site that you are open to hearing from your visitors that you will act on their feedback.  There aren't enough websites that are actively encouraging people to report their accessibility problems.  

This site isn't currently WCAG 2.0 AA compliant but is quite accessible. We will do a full audit at some point and know that there will be many areas where we can improve.  I also know that we will need to set up mechanisms to maintain and enhance this over time as accessibility is a journey and not a destination. The Internet will continue to evolve and we will need to keep up, working to ensure that our site works with the devices that people are using.  

Use the Guidelines Properly

It is important to refer to the WCAG guidelines as they are an important evaluation framework. It is useful as an impartial guide to help resolve disputes about how to implement your site. I would highly recommend hiring a 3rd party to evaluate your sites accessibility and to pick a desired conformance level to strive towards. Keep in mind that if your goal is to make the claim that your site is WCAG 2.0 compliant you will be required to date the claim, include a link to the guidelines with title, version, define the conformance level, list the pages which have been evaluated & also list the technologies that have been used.  

WCAG evaluation is not just something that you can simply budget for after you've launched your new site.  It's an ongoing process, that involves educating editors, investing in training and participating in software communities that create the tools that your site uses.  

My Steps to Evaluate a Site's Accessibility:

1. start with a system, like Drupal 7, that has undergone accessibility enhancements and where the accessibility issues are largely known already (there will be fewer problems to find);
2. use automated tools like the Wave Toolbar and A-Contrast to pick out obvious problems for your users (these tools will find the low hanging fruit);
3. provide your content team with tools to do simple automated testing, like CSS Holmes, to review their content before it's published.
4. hire a 3rd party to audit your site so that you can have someone else look for barriers that an automated tool can't evaluate (experts will help identify the less obvious problems);
5. bring in focus group of users who use assistive technology to look for further enhancements (Assistive Technology users will give you good feedback about what works for them);
6. make your site as open and welcoming as possible to submit feedback with accessibility problems that users may have experienced (your users are the ultimate experts, listen to them);
7. work to implement suggestions from #5 quickly, plan to regularly re-visit steps 2-4 and make sure you are keeping up with the latest stable releases of the software that you use.