The adoption of the W3C Web Content Accessibility Guidelines (WCAG) 2.0 standards has been a great success, with many governments around the world either implementing or committing to implement them over the coming years.
While most agree in principle that WCAG 2.0 should be implemented, there is considerable debate about the level to which the guidelines should be implemented. Generally the debate is between the minimal ‘A’ standard or the more comprehensive ‘AA’.
But there is a third accessibility option, the ‘AAA’ standard, which would take websites up to their maximum accessibility potential. So why is ‘AAA’ so rarely discussed or considered as a viable option?
If we leave the multimedia requirements for a moment, the guidelines generally don’t seem too onerous. There is a requirement for a 7:1 contrast ratio with some exceptions such as logos, there should be low or no background noise, text shouldn’t be contained in images and everything needs to be accessible by keyboard with no exceptions.
The next few guidelines talk about the removal of flashing or pulsing media, the ability of users to be able to stop things that interrupt the work you might be doing, good help and support with filling out forms, and being able to log back into a website that’s timed out without any loss of data. At this stage, ‘AAA’ compliance sounds like something every website should have!
Interestingly, one of the key issues raised about ‘AAA’ is not so much a developer issue but more for the content author. The guidelines are fairly strict about the language that content should be targeted at, stating that if anything on a web page is written at a level higher than a lower secondary student, additional explanation must be provided. While understandable, in the social media age many people feel that this is too restrictive and impinges on people’s right to publish pretty much whatever they like, and however they like to write it. However, from a developer perspective, there’s still no major issue on this point.
The real challenges for developers though are the three main multimedia points: sign language provision, extended audio description and alternatives for live audio. The latter is not as much of a problem today as it used to be, with many automated technologies and services now available that can provide on-the-fly translation of audio into text, and publish that text online. The first two, however, could be problematic from the perspective of the developer.
The creation of sign language requires a lot of time and effort, and some argue that the amount of time and effort required is almost as much as the time and effort required on all the other WCAG 2.0 guidelines combined. Existing content first needs to be translated into sign, then it needs to be recorded, then integrated into an existing web video, and then finally published online. Logistically, this can be a difficult process for developers, and often web development budgets don’t factor in the need for hiring staff to produce sign language content. Unlike other WCAG 2.0 guidelines which are more developer-specific, the decision to include sign language on a website is one that needs to be made higher up the chain and often catches developers by surprise when they’re handed the guidelines as the site’s being built and told to ‘do this’, by which time it’s usually too late.
Extended Audio Description (AD) is similar to regular AD except that the video can be stopped to include extra description. For example, if the audio describer is trying to describe a lengthy battle scene in a movie but doesn’t have enough room in-between dialogue to fit in the explanation, the video can actually pause itself while the describer finishes describing it. Not only is this difficult for developers trying to implement the video online, but it also represents a standard that is rarely if ever used in the movie and television industry. To try and implement extended AD, when the big motion picture companies don’t see it as viable in cinema or TV, makes it a tough ask for developers, and results in ‘AAA’ being almost unachievable.
So is ‘AAA’ worth it? Well, in most cases, no. Not because it’s not worthwhile for people with disabilities to have, it’s just too hard for developers to do in the context of the modern web.
However, there is no need to dismiss the guidelines entirely. There are definitely aspects of the ‘AAA’ that are worth it, particularly those that don’t require much additional work by developers such as the non-multimedia guidelines.
In very specific circumstances, such as the creation of a website that is particularly for people who are Deaf or hearing impaired, or people who are blind or vision impaired, all parts to ‘AAA’ should be applied. This way the people that need ‘AAA’ have access to it, and the rest of the time websites continue to be developed to the more practical ‘A’ or ‘AA’ standard.
Further information on the WCAG 2.0 guidelines can be found in the New Media section of the MAA website, or directly from the W3C Web Access Initiative (WAI) website.
Top of page