WCAG Conformance is Not Enough
Plain language summary
The Web Content Accessibility Guidelines say that your website has to pass 55 accessibility tests. But even if all 55 are passed, there is more to consider if you want an accessible website. This is because some of the tests are imperfect, they don't test for everything, and other reasons.
A common refrain
"Just because something is WCAG-conformant, it doesn't mean that it's accessible." This is an often-repeated refrain in the accessibility field, and it's correct, without a doubt.
If you have been hearing a lot of hype around WCAG conformance and your obligation to do it, this may come as a surprise to you.
Understand, people who repeat this refrain aren't saying that the WCAG are useless, or that they do not have a place in the accessibility field. Nobody is arguing that we should throw WCAG directly into the bin, or that you should just ignore them!
But it is a complicated issue with some nuance.
This article will distill the bones of this discussion into four big bullet points for why WCAG conformance does not guarantee accessibility. Before we dig in, let's start with a primer.
Some Background
The Web Content Accessibility Guidelines are a technical checklist developed by the W3C. They are referenced directly in the Accessibility for Manitobans Act, as well as crucial accessibility legislation like Title II of the Americans with Disabilities Act, the Accessibility for Ontarians with Disabilities Act, Section 508 of the Rehabilitation Act (in the US), EN-301-549, Canada's implementation of EN-301-549, CAN/ASC-EN-301-549.
The WCAG checklist is internationally recognized as being a standard that gives some baseline level of accessibility.
WCAG is maintained and developed by the World Wide Web Consortium. The World Wide Consortium was founded by the inventor of the internet and is responsible for drafting the technological standards that make the internet possible. The World Wide Web Consortium is an international non-profit and their work is driven by corporations and members of the public participating in a volunteer capacity.
Accessibility is one of the World Wide Web Consortium's most strongly held values, and WCAG is one of the World Wide Web Consortium's many projects. Just like any of their projects, the standard was formed by specialists from across the globe working as volunteer contributors.
WCAG and Me
I have immense respect for the WCAG, and for every contributor who continues to update the Understanding documentation and ensures the robustness of the checklist remains intact.
As I view digital accessibility as a human right, I find that standards like the WCAG are essential to ensuring digital accessibility can be legally protected.
So why do we say that WCAG-conformance doesn't necessarily lead to accessible experiences?
1. Too Black and White
Each checkpoint of the WCAG checklist is binary pass/fail. A lot of the wording leaves room for 'loop-hole adjacent' interpretation. There are a lot of things that may seem like they only pass on a technicality.
As Patrick H. Lauke points out in his talk These (Still) Aren't the SCs You're Looking For, it simply is the case that the checklist is imperfect. When WCAG doesn't give you what you want, you must lean on other arguments and draw in resources outside of WCAG. But Lauke argues that claiming WCAG does things that it does not do, especially when conducting 'WCAG audits,' puts the integrity of the entire field into question.
2. 'Baseline' Accessibility
WCAG also doesn't try to cover every single kind of inaccessibility. In its baseline, it excludes several accessibility measures that it believes are too cost-prohibitive to mandate for organizations across the board. These include sign language, transcripts, reading level, and more.
3. Ultimately Discretionary
There are some holes in WCAG where interpretation tends towards the subjective.
I have a background in captioning, and so I have a quite high standard for what I believe captions must include. But WCAG itself doesn't elaborate any requirements for captions beyond stating that captions must be 'provided.'
There are other checkpoints where there is more wiggle room for subjective interpretation. While WCAG audits should be repeatable, especially with certain checkpoints, they are not.
When the law is ambiguous, lawyers and judges lean back on case law and precedent. When the WCAG checkpoints are ambiguous, WCAG auditors lean back on our opinions.
4. Doesn't Specifically Address Usability
WCAG doesn't force you to make a good product. If your product is absolutely garbage for everyone to use, it doesn't tell you that you need to change something so that people can use it.
Imagine you have an app. To register for the app, you first have to pass a skill-testing question, where you have to push a button over and over 3 million times in order for your account to be validated.
Well, if that button is keyboard accessible, has proper colour contrast, has an accessible name, is set up with appropriate status message, has instructions, takes input on the up-event, and meets other relevant WCAG checkpoints, we can say it meets WCAG conformance requirements and is baseline accessible!
If it's inaccessible to everyone, WCAG doesn't consider it to be a matter of accessibility anymore.
Nevertheless, WCAG is Good!
WCAG is immensely useful, and we can fix a lot of inaccessibility by leaning on WCAG. In terms of pursuing accessibility through legal channels, it is the best tool we have so far to accomplish the task.
It is also a strong educational tool. Despite its loopholes, the project has given birth to a whole bunch of non-normative documentation and educational initiatives that strengthen our collective capacity to pursue digital accessibility.
But evidently, as has just been demonstrated, there are dimensions to accessibility that WCAG cannot account for.