In testing WCAG 2.1 Level AAA, we looked at the twenty-eight success criteria for WCAG 2.1 Level AAA and suggested ways to go about testing against them. If you follow this process you will, almost certainly, have found cases where your site or application is not meeting the requirements of WCAG 2.1 Level AAA. But, as WCAG itself notes:
It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content.
So, how do you decide what to fix and what to ignore?
Three groups of issues
When performing any sort of assessment there are generally three groups issues fall into:
- Won't fix
- Not relevant
Most of the time issues will be in the Fix or Won't fix group; so why would something that is Not relevant be included as a test in the first place? Because you've tested against a defined set of criteria, you may find issues that just aren't relevant just as you would at Level A and Level AAA.
Let's look at the different groups and what issues you should include in each.
These issues are, naturally, the ones you intend to fix. You can identify these in two ways:
- Does this issue present an accessibility barrier to your audience?
- Does fixing the issue significantly improve the user experience, particularly for people with disabilities?
The first point is something that differentiates WCAG 2.1 Level AAA from Level A and Level AA. While Level A and Level AA are both intended to be used for general accessibility, WCAG 2.1 Level AAA is intended to be used for specific content, audiences, or circumstances.
For example, do Deaf users make up a large proportion of your audience? If they do, then a lack of sign language may be a significant barrier, so meeting SC 1.2.6 Sign Language (Prerecorded), may be more important for your site or application than others.
The second point captures more general benefits to meeting WCAG 2.1 Level AAA. An application for a summer music festival may benefit from greater contrast for text as it will (hopefully!) be used in bright sunlight. SC 1.4.6 Contrast (Enhanced) could be a success criterion you want to meet.
You may decide there are things you won't fix. It may seem odd to test against a standard and then choose not to fix issues, but for WCAG 2.1 Level AAA, this is expected for reasons described in understanding WCAG 2.1 Level AAA.
For example, SC 3.1.5 Reading Level is as follows:
When text requires reading ability more advanced than the lower secondary education level after removal of proper names and titles, supplemental content, or a version that does not require reading ability more advanced than the lower secondary education level, is available.
However, for a scientific journal with an audience that is predominantly people with an advanced education level and used to reading scientific articles, this may not be necessary. Simplifying the language may, in the worst case, make the content less accessible to its intended audience if less precise terms are used to meet a lower reading level.
This doesn't mean that you should always ignore issues raised. You may want to use the failed criteria as the basis for setting your own requirements, perhaps using a higher reading level as your target.
If there are issues that you don't want to fix now, include these in the Fix group; fixing later is still fixing, and so should not be included in the Won't fix group.
The important thing that Level AAA testing gives you is the ability be able to make an informed decision. You should document whatever decision you make, along with your reasoning, so that the decision can be reassessed in the future or applied consistently in other circumstances.
This is everything else, the issues that are not applicable to your content. You haven't failed them, they just haven't been tested against. If you don't have multimedia content then all of the criteria under Guideline 1.2 Time-based Media do not apply.
You shouldn't forget about them, though. Content and features of sites and applications constantly change. Keep this group of success criteria in mind as features are developed and content is added, and test against them if they become relevant.
What to fix first
When testing against WCAG, the level gives you the first piece of information that you need to determine the order to fix issues. In most cases, you should fix Level A issues first, followed by Level AA. Sometimes, when a Level A criterion is a stricter version of a Level AA criterion, you can fix both at the same time, so it's worth looking ahead to Level AAA issues at the same time. The same applies to evaluating Level AAA issues; check if there is an enhanced equivalent at Level AAA that you could meet.
For example, if you need to increase the contrast of a piece of text, are you going to increase it to 4.5:1 to meet the Level AA requirement and then think about increasing it to 7:1 to meet the Level AAA criterion later, or does it make more sense to jump straight to the enhanced contrast level? Almost certainly the latter.
The second thing to consider is the severity of the issue. This is less likely to include Level AAA criteria, as they are, by their nature, generally less critical than Level A or Level AA criteria. The same principle of looking ahead applies here as well. Remember, WCAG success criteria define the minimum expectations; Level AAA often raises the minimum expectation but often does so in ways that will benefit your entire audience.
The third thing to consider is your audience. As Level AAA criteria may more beneficial to specific user groups than the general population, you should always look to it if you have a particular target audience. If your target audience is predominantly a group of people with disabilities that would benefit from one or more Level AAA success criteria, then you may even wish to prioritise these over Level A or Level AA criteria.
Testing against WCAG 2.1 Level AAA is a great way to get a better understanding of how your site or application might be improved beyond the Level A and Level AA success criteria. By including specific criteria in your regular testing, you can ensure that you are not just meeting but exceeding the legal requirements for accessibility in most countries and, more importantly, making your site or application more accessible and more usable for people with disabilities.
We like to listen. If you have a project, product, problem, or idea that you want to discuss, get in touch!