The Short Version
Read this if you’re disinclined to read the entire list of specific WCAG Success Criterion and look at how each can be tested.
If someone was to ask me what I consider to be my biggest strengths when it comes to accessibility, I’d say it is in testing. I’ve been involved in doing accessibility testing for the last 9 years of my career. I’ve used nearly every enterprise tool that exists for accessibility, been involved in developing them, developed my own, and have done hundreds of hours of manual code review, use case testing, and usability testing. As tedious and boring as some people make testing seem, I truly enjoy accessibility testing. I think of myself as a CSI, looking for clues left behind by developers. One thing I am interested in is finding the most efficient ways to do testing.
The thing about automatic testing is that there are some things which can be tested by machine testing quite reliably. For instance, either you have provided an alt attribute for IMG elements or you have not; either you have provided a LABEL for form fields or you have not. These things are easy to verify with machine testing and they should be done with machine testing – I call these “Automatically Testable”. On the other hand, there are things which can be tested for but the results would need to be verified by a skilled human reviewer. For example, while machine testing can verify that the alt attribute exists for an image, it cannot tell you whether the value supplied for the alt attribute is a suitable alternative for the image. That requires a human. Automatic testing can look for common types of failures, such as alt text that is too long, too short, or contains typically ambiguous words. I call these “Manual Verification Required”. Finally there are some items which are either too difficult for a machine to do or too subjective in nature for a machine to do with any degree of reliability. I call these “Manual Only”.
With the above in mind, I’ve undertaken an exercise to determine exactly what can be tested. Here is what I’ve found:
Testability of Best Practices by WCAG Level
|WCAG Level||Auto||Manual Ver. %||Manual Only %|
What does this mean?
In short, it means that relying solely on automatic testing is probably a bad idea. I still maintain that automatic testing has significant value due to increased efficiency, but it is very clear to me that one cannot rely only on a tool to test for accessibility. A skilled reviewer is critical and the more risk you have, the more important skilled humans become.
These three tables detail how many items can be tested for using automated testing. Also provided are items which can be found with automated testing but require manual verification, and finally, those things which can only be reviewed manually. For a more detailed description see the section on Methodology, below.
|S.C.||Total BPs||Auto||Manual Ver. %||Manual Only %|
Total % by type, Level A
- Automatic: 25%
- Manual Verification: 29%
- Manual Only: 46%
|S.C.||Total BPs||> Auto||Manual Ver. %||> Manual Only %|
Total % by type, Level AA
- Automatic: 17%
- Manual Verification: 41%
- Manual Only: 41%
|S.C.||Total BPs||Auto||Manual Ver. %||Manual Only %|
Total % by type
- Automatic: 23%
- Manual Verification: 24%
- Manual Only: 53%
How I arrived at this data
The data presented above does not use or describe any information from any previous or current employer. Instead, I used my own empirical background in accessibility testing since 2003 by doing an exercise much like the following:
- Create a list of all WCAG Success Criterion, organized by Level. There are 3 levels in WCAG, Level A, Level AA, and Level AAA
- For each Success Sriterion create a list of the applicable Best Practices. In other words, answer this question: What does it really take to conform with this Success Criterion? Under Success Criterion 1.1.1, for example, I’ve created a list of 26 Best Practices that relate to that single Success Criterion. Others may have only one, most others range between 2 and 6
- For each Best Practice, determine whether it can actually be tested for using automatic means.
- If the answer is ‘yes’, then I mark that as an item under the ‘Auto’ column.
- If a tool can test for a specific Best Practice, but the results must be verified by a human, then I marked it in the ‘Manual Verification’ column.
- Finally, if the Best Practice is too complex or too subjective to be handled effectively by an automated tool, I marked it as ‘Manual Only’
- This list does not take into account the capabilities (or lack thereof) of any particular tool. The only consideration I gave was whether I feel that a tool should reasonably be able to test something effectively or not. Tools tend to vary quite considerably in their capabilities, so as the saying goes: Your mileage may vary.
- Some tool vendors may voice disagreements with this list and assert that they can test for some of the items that I show as ‘0%’. I would argue that the reliability of these tests would be so low as to not be considered.
- The fact that an item can be tested for automatically doesn’t mean that it can find every single instance of a violation automatically. This is especially true in the case of bleeding edge technologies (like WebGL, for instance)
- Your list of Best Practices may differ from mine and may be more or less rigorous than mine. Mine, for example, are generally isolated to HTML, CSS, and Client-side scripting. To get a head start on determining your own Best Practices, take a look at the WCAG Techniques information
Why I created this resource
This list should not be taken as a stab against tools and tool vendors. I’ve said numerous times that we should do automatic testing first. When done properly, automatic testing offers a degree of efficiency that cannot be matched by other methods. However, that doesn’t mean that we should leave our compliance up to automated testing. As the tables above show, there are 9 WCAG Success Criterion (in Level A and AA) that cannot be tested for in any meaningful manner using a tool. There are another 13 that can be tested for automatically but require a human to verify. Full compliance and risk mitigation always requires the involvement of a skilled professional reviewer, even when you have a tool as well.