Understanding WCAG Level
With the upcoming eventual issuance of a Final Rule for Section 508 Refresh and deadlines for compliance with the Accessibility for Ontarians with Disabilities Act (AODA), as well as increasing rate of Web Accessibility-related lawsuits, I’ve become increasingly aware of people’s frequent misunderstanding of the purpose of what the term ‘Level’ represents in the Web Content Accessibility Guidelines (WCAG). I hope to help clarify this in this post. Keep in mind, this is my interpretation, because as I’ll mention later, the WCAG Working Group hasn’t been as clear as they should have been.
In the first version of WCAG, the term used was ‘Priority’, and their description of Priority was quite clear. Priority represented the impact on users:
Each checkpoint has a priority level assigned by the Working Group based on the checkpoint’s impact on accessibility.
A Web content developer must satisfy this checkpoint. Otherwise, one or more groups will find it impossible to access information in the document. Satisfying this checkpoint is a basic requirement for some groups to be able to use Web documents.
A Web content developer should satisfy this checkpoint. Otherwise, one or more groups will find it difficult to access information in the document. Satisfying this checkpoint will remove significant barriers to accessing Web documents.
A Web content developer may address this checkpoint. Otherwise, one or more groups will find it somewhat difficult to access information in the document. Satisfying this checkpoint will improve access to Web documents.
You may note the key words in use in the above content which indicate requirements in accordance with RFC 2119.
One of the problems with this approach of indicating priority based solely on user impact is that it doesn’t take any other factors into consideration. “In the real world”, as they say, there are other things to consider beyond user impact. While it would be nice to only have to concern ourselves with whether or not all users have equivalent access, the reality is that logistical, technical, or resource limitations must be considered as well. I’ve discussed this previously in Prioritizing Remediation of Web Accessibility Issues but in short we need to understand that each organization has a mission to fulfill and accessibility must be considered as it relates to the organization’s goal in achieving that mission. Proper prioritization allows us to improve accessibility without jeopardizing that mission.
The WCAG Working Group’s switch to ‘Level’, for version 2.0 is more than just symbolic. “Level” and “Priority” are not synonymous. Unfortunately, the use of ‘A’, ‘AA’, and ‘AAA’ does imply a ‘Good’, ‘Better’, ‘Best’ type of progression to most laypeople. Or, as many tend to view it: “Good enough”, “Better”, and “Extra Credit”. If you read carefully you’ll see that the WCAG Working Group clearly understood that user impact isn’t the only concern.
Success Criteria – For each guideline, testable success criteria are provided to allow WCAG 2.0 to be used where requirements and conformance testing are necessary such as in design specification, purchasing, regulation, and contractual agreements. In order to meet the needs of different groups and different situations, three levels of conformance are defined: A (lowest), AA, and AAA (highest). Additional information on WCAG levels can be found in Understanding Levels of Conformance.
But that’s the only normative discussion of what levels mean. In my opinion, they’re partially responsible for the confusion people have regarding Level by saying: … A (lowest), AA, and AAA (highest)… because this again implies synonymy with “Priority”. But, if you follow that link in the passage above, you get this:
First, there are a number of conditions that must be met for a Success Criterion to be included at all. These include:
- All Success Criteria must be important access issues for people with disabilities that address problems beyond the usability problems that might be faced by all users. In other words, the access issue must cause a proportionately greater problem for people with disabilities than it causes people without disabilities in order to be considered an accessibility issue (and covered under these accessibility guidelines).
- All Success Criteria must also be testable. This is important since otherwise it would not be possible to determine whether a page met or failed to meet the Success Criteria. The Success Criteria can be tested by a combination of machine and human evaluation as long as it is possible to determine whether a Success Criterion has been satisfied with a high level of confidence.
The Success Criteria were assigned to one of the three levels of conformance by the working group after taking into consideration a wide range of interacting issues. Some of the common factors evaluated when setting the level included:
- whether the Success Criterion is essential (in other words, if the Success Criterion isn’t met, then even assistive technology can’t make content accessible)
- whether it is possible to satisfy the Success Criterion for all Web sites and types of content that the Success Criteria would apply to (e.g., different topics, types of content, types of Web technology)
- whether the Success Criterion requires skills that could reasonably be achieved by the content creators (that is, the knowledge and skill to meet the Success Criteria could be acquired in a week’s training or less)
- whether the Success Criterion would impose limits on the “look & feel” and/or function of the Web page. (limits on function, presentation, freedom of expression, design or aesthetic that the Success Criteria might place on authors)
- whether there are no workarounds if the Success Criterion is not met
Unfortunately that text isn’t much clearer. They’ve clearly indicated what their considerations were when setting the Level on Success Criteria but not which considerations were applicable to which Level. They’re just saying “this is what we thought about”. Furthermore, the “Understanding WCAG 2.0” document isn’t Normative, but informative. The 3rd sentence of that document’s abstract states: Please note that the contents of this document are informative (they provide guidance), and not normative (they do not set requirements for conforming to WCAG 2.0).
It is unfortunate that they’ve never clarified what each individual Level means. In fact, they did have a much clearer explanation of each level in an early draft of WCAG 2.0 from 2005.
Conformance means that Web content satisfies the success criteria defined in this document. This section outlines the conformance scheme used throughout this document.
The success criteria for each guideline are organized into three (3) levels of conformance.
- Level 1 success criteria:
- Achieve a minimum level of accessibility through markup, scripting, or other technologies that interact with or enable access through user agents, including assistive technologies.
- Can reasonably be applied to all Web resources.
- Level 2 success criteria:
- Achieve an enhanced level of accessibility through one or both of the following:
- markup, scripting, or other technologies that interact with or enable access through user agents, including assistive technologies
- the design of the content and presentation
- Can reasonably be applied to all Web resources.
- Level 3 success criteria:
- Achieve additional accessibility enhancements for people with disabilities.
- Are not applicable to all Web resources.
Note: Some guidelines do not contain level 1 success criteria, and others do not contain level 2 success criteria.
This method of grouping success criteria differs in important ways from the approach taken in WCAG 1.0. In WCAG 1.0, each checkpoint is assigned a “priority” according to its impact on accessibility for users. Thus Priority 3 checkpoints appear to be less important than Priority 1 checkpoints. The Working Group now believes that all success criteria of WCAG 2.0 are essential for some people. Thus, the system of checkpoints and priorities used in WCAG 1.0 has been replaced by success criteria grouped under Levels 1, 2, and 3 as described above.
My Interpretation of WCAG Level
The first thing to keep in mind is that all WCAG Success Criteria are important. No, I don’t mean this from the perspective of a bleeding heart idealist. I mean that there are no “nice-to-haves”, these are all things that you should consider including in your web-based system. The difference in Level has a lot to do with weighing all those things I talked about with respect to an organization’s other concerns.
- Level A Success Criteria are those which will have a high impact on a broad array of user populations. In other words, they (usually) don’t focus on one type of disability only. They will also have the lowest impact on the presentation logic and business logic of the site. Finally, implementation of these requirements will typically be the easiest.
- Level AA Success Criteria will also have a high impact for users. Sometimes only specific user populations will be impacted, but the impact is important. Adherence to these Success Criteria may impose changes to a system’s presentation logic or business logic.
- Level AAA Success Criteria are often focused on improvements for specific user populations. They may be difficult or expensive to adhere to, depending on platform limitations. The benefit-to-cost ratio may be low enough to deprioritize these items
What Level to “Comply” with
Perhaps the reason why the WCAG Working Group did not add an explicit description to each level is because they’re all important. Or perhaps it is because the delineation isn’t black-and-white but rather shades of gray. In any case, here’s my advice:
- Comply with everything you can reasonably comply with, given your personal environment
- In my experience, there really is no excuse to not to meet all of the Level A Success Criteria, without exception
- Sufficiently skilled designers & developers should be able to meet Level AA Success Criteria that don’t require significant change to business logic or branding. In new work, it is my opinion that only platform limitations would prevent meeting Level AA.
- There are many Level AAA requirements that can be met with very little effort and minimal change to business or presentation logic.
On that latter point it bears mentioning that just because it says “Level AAA”, that doesn’t mean you should disregard it. For instance: “2.4.10 Section Headings: Section headings are used to organize the content. ” It should be easy enough for web content writers to use headings in their content and for web development staff to use proper heading markup that it is silly not to meet this Success Criteria. In short, WCAG Level is not an indication of user impact or overall importance.
WCAG Level and Risk of Lawsuit
I think it is important for people to understand that nobody has ever been sued because they didn’t meet a specific WCAG Level or violated certain specific criterion. None. Never. In all cases I’m aware of, organizations get sued because users can’t accomplish core system tasks, irrespective of any specific WCAG Level. The only time WCAG Level comes into play is when determining settlement criteria. In other words, you’re better off focusing on usability for persons with disabilities than you are on WCAG Level, instead using WCAG information (both normative and informative) as a resource for learning and reference for staff and vendors. For more information on risk, see Reduction of Legal Risk as Web Accessibility Business Case.