I've taken the notes about the process we are going through for our own site & attached it to this Drupal Accessibility Group Wiki Page. Please feel free to edit it.

We have gotten a number of RFP's in the past that have stated WCAG 2.0 AAA compliance as one of the requirements that they would like to have in their response.  It is great when folks are aware enough about accessibility issues that they can state of of their goals is to achieve the highest level of accessibility for their site. Really, who wouldn't want to have their website be universally accessible to their users?

However, it isn't an achievable goal for the majority of websites.

Nobody should be claiming WCAG 2.0 AAA

For a website site with any complexity at all to it:

• It takes a huge accessibility budget to maintain. It is very time intensive to run every page of the site through the quick reference provided by the WAI. Even running through it through WebAIM's simplified checklist is a lengthy process. 
• Some of the WCAG 2.0 AAA requirements can conflict with each other or other WAI guidelines. You have to know your users, and learn where to make compromises.
• There probably aren't any examples out there of sites that are 100% compliant.  Individual pages might comply, but will still need to be reviewed on a regular basis.
• The WAI is wisely focuses on broad objectives not on specific technology and the technology is perpetually changing. A user's browser or screen reader upgrade can easily break accessibility.{C}

The Response from the Twitterverse

I decided to post a question out to the twitter accessibility community to see if anyone had a website that they knew of that they were confident was WCAG 2.0 AAA compliant. I asked both Does anyone have an active, dynamic website that they complies 100% with WCAG 2.0 AAA? #a11y and Can a focus on achieving WCAG guidelines get in the way of actively listening to the needs and experiences of users w disabilities? #ux #a11y

I think Matt May's response was one of my favourites, it was also the first I think you can find unicorns with less trouble. Matt lobbied to remove the AAA standard from WCAG 2.0 when he was at W3C. 

I've been working with Everett Zufelt now for over a year on Drupal 7 accessibility and his response was, You just need to tell them that they're taking the wrong exam. WAI states explicitly that AAA is not always the right exam. I've had some great conversations about guidelines with Everett in the past. People often see guidelines wrongly as mandatory items.

The most useful pieces of feedback I received was from Sarah Bourne who said in two tweets Actual accessibility is the mission. Guidelines are just tasks.Testing, listening to other users also tasks. When tasks are in conflict, you go back to the mission to resolve them. This post brought in the most important actor, the user.  Later Sarah added a problem with AAA is that optimizing for 1 group can disadvantage another. Compromise required, but again, base on mission.Knowing your users is critical and being receptive to their feedback is key to having a site which is really accessible.

The author of AccessibleTwitter and the WebAxe podcast, Dennis Lembree put forward the AccessibleTwitter site as a site that is extremely close to being WCAG 2.0 AAA compliant. The best part of his response was modeling how every site should be to their users If you find any issues of non-compliance, I'd be happy to address.

Since we're both in Ontario, I've talked with Sandi Gauder in the past about the AODA. Although the standard hasn't been set yet, it is likely that it will be based on the WAI guidelines when it is released. Sandi states, Maintaining is the key. With more site content being driven by a CMS, maintaining conformance is the challenge. With more people adding content, the more complicated it is to retain compliance. 

John Foliot's been working on HTML5 and addressing accessibility issues with this new standard and he's so right that AAA is about more than just technology. Ultimately as John says, WCAG2 is about choices no such thing as single solutions. Later John made the great point I generally believe mapping A, AA, & AAA to MUST, SHOULD, MAY helps. RFC 2119

Guidelines need to be put in proper context. As Leonie Watson tweets It's part of an approach. Thinking about guidelines/testing/development/any part of it in isolation makes no sense.

Matt and Cliff Tyllick, who has also done a lot of work in improving Drupal's accessibility, both agree that People should look at AAA as optional and achieve all that they can easily or that make sense in their case.

If we can get folks thinking of accessibility as a process rather than a destination I think we'll be better off.  The WCAG AAA are a goal that we will need to perpetually strive to achieve, but never actually attain. 

A Reasonable Approach to Serious Accessibility

Now, that we've shot down the hope of putting a WCAG 2.0 AAA logo on the bottom of your page, what is OpenConcept's approach to Accessibility? 

Our present site is horrible.  It's based on a very old version of Drupal and we will be upgrading both the design and the code base in the next few months.  We are upgrading to Drupal 7 because this is the system we know and are very familiar with the accessibility enhancements that will come with it.  Starting with a fairly accessible base reduces the number of things that we will be required to test.  We will be building our theme on one which is already committed to producing an accessibility base.

We will be actively reviewing our site with web based evaluation tools like our current favourite, WebAim's WAVE. But we will also be using other validation services to review our site. 

There are a number of modules that we can add to enhance accessibility within Drupal. These haven't been released for Drupal 7 yet, but when they are we can add them in to address known issues. 

We will want to add in support for WAI-ARIA where it is clear that it will enhance the users experience. When this is guideline is finalized will will review it again to ensure that we have implemented the standards that they are suggesting.  

At this point it would make sense for us to define a few representative pages and ensure that they comply with WCAG 2.0 AA's guidelines.  This is a difficult, but achievable task. Because we're using a content management system, many of the problems we identify will be applicable to many other pages of the site.  Changes can often be done in one place to correct the problems.

Next we'll be inviting individuals with expertise in accessibility to review the site and give feedback on specific representative pages (home, contact, feedback).  If we are specific about the types of pages we will be more able to get feedback that we can apply to the rest of the site. 

Finally it is critical to openly and actively invite people to report accessibility problems. Reporting them should be easy and should provide people with a number of different ways to report problems.  This page is of course one of the ones that should be reviewed most closely as there is no point sending someone to a clearly inaccessible web form. CAPTCHA's are a problem as usual.

As a follow-up it will be important to schedule time to check a random number of pages to find/fix problems that may have developed over time. 

BS-8878: A Process Oriented Standard

Leonie Watson pointed me towards BS-8878 as a code of practice that includes “recommendations for building and maintaining web experiences that are accessible to, usable by and enjoyable for disabled people.” I haven't looked at it in any depth, but do like the focus on managing the process & involving people with disabilities. Both those seem to be elements that critical issues that organizations need to incorporate in improving their web presence.

The goal is to be working continually to improve access to our website for everyone. If you've got any questions or comments on this post, please leave a comment below.