WCAG 2.0 vs. New Law: Why Legal Compliance Requirements for Web Accessibility Must Be Different
When I read about the wholesale adoption of WCAG into the law, a little-big piece of me dies inside.
Whether it’s the State of California requiring state agencies comply with WCAG 2.0 AA, Section 508 of the Rehabilitation Act being revised to incorporate WCAG 2.0, or three European Standards Organizations (CEN, CENELEC, and ETSI) updating EN 301 549 to adopt WCAG 2.1, it’s wrong.
It’s wrong. It’s wrong. It’s WRONG.
There is so much groupthink, herd mentality, and acquiescence going on here; not one person in the entire auditorium is raising their hand to ask the elephant-in-the-room question:
Do we even want WCAG governing web accessibility?
WCAG Has Serious Flaws
A 10 second background before we start.
The Web Content Accessibility Guidelines (WCAG) are recommendations for making the web more accessible to people with disabilities.
These guidelines are created by the World Wide Web Consortium (W3C) under the Web Accessibility Initiative (WAI).
There are different levels of conformance (A, AA, AAA) under the different versions (1.0, 2.0, 2.1) but WCAG 2.0 AA is what is loosely asked of most private entities.
Basically, you’ve got an international community that’s trying to create uniform web standards that everyone can follow to make the web a more accessible place for everyone.
Sounds like popcorn, unicorns, lollipops, and candy shops, right?
Case closed, we can have one of our interns write a few thousand words to pad the intro, copy and paste WCAG 2.0 and 2.1, and then shove a few more pages in at the end for good measure.
Hey, we’re finished with this whole web accessibility thing and it’s not even noon yet.
What do you think? Golf or steakhouse?
Hmmm, I don’t know, I’m feeling kind of golfy…Maybe golf first and then steakhouse or…
While WCAG provides a thank you-worthy head start in creating law on website accessibility, it isn’t a ready-made law, not even remotely close.
I know there’s a lot of momentum behind WCAG but have you actually sat down and looked at some of the stuff they do and do not require?
Let’s take a gander…
WCAG actually permits pop-ups!
Automatic pop-ups (without prompting) can completely disorient persons with disabilities (including people who are blind, have low-vision, or have cognitive impairments), causing frustration of purpose and significant loss of time!
Just for a moment, imagine that you’re shopping on Amazon and you can not see your device (laptop, tablet, phone) screen. Instead, you’re listening to what is on the page with a screen reader. Right in the middle of checking out a potential book, a new window pops-up, changing the page you’re on and the content that’s being read to you.
For blind users, the pop-up box can appear, the screen reader will read through it, and then the screen reader will reset and start re-reading from the top of the original page.
Again, WCAG 2.0 AA permits pop-ups. I’m possibly appalled and moderately shocked by this.
Similarly, WCAG 2.0 AA allows for videos to autoplay when you open a web page. This can be distracting for anyone but especially for people with disabilities!
However, in another regard, WCAG 2.0 AA gets Ford tough on videos, requiring full audio descriptions on videos, check it out:
From success criterion 1.2.5 (yes, level AA): an audio description of the important, non-audible information should be conveyed during pauses in the video — YIKES!
That’s a tough monkey to banana.
Think of running a website chock-full of videos and having to go in and edit all of those to include a new audio description that provides information about actions, characters, scene changes, and on-screen text that are important and not described or spoken in the main audio.
If nothing else, the incongruence between success criteria is concerning, right?
One hand you’ve got this Mount Everest, aspirational commandment zesting for the nth degree of accessibility and, then, on the other, you’ve left the barn door completely open, not really caring who comes or goes, it’s whatever.
Oh, and by the way, there are more of these types of examples within the 38 success criteria that comprise WCAG 2.0 AA.
I’m just curious, has anyone else actually read through WCAG 2.0? Not just the CliffsNotes from my other Medium article on ADA Website Compliance but the actual documentation.
Going once…going twice…okay, I see…
Anyways, my commentary on WCAG isn’t so much of a critique as it is a labeling of the now overused and popularized saying, “it is what it is”.
And what it is is an attempt at establishing technical standards for web accessibility.
Again, the Web Content Accessibility Guidelines (WCAG) are TECHNICAL guidelines for web standards; they were NEVER INTENDED TO BE LAW.
Of all the creators of WCAG, I see oodles of developers and accessibility advocates but I don’t spot a single attorney or lawmaker in the whole lot.
What does this mean?
This means a group of people have done an amazing job at creating a great list of technical ideas with which to create law from but we cannot expect that their standards are ready to become law as-is.
Good law has the following characteristics:
- Clear and concise
- Easy to follow
- Easy to spot violations
WCAG does not embody these characteristics.
Its language is unclear. Its requirements are hazy and overlap. It can be difficult to understand. And it’s not easy to know if your website meets all of the guidelines.
That last part is a big one because it opens the door for garbage lawyers to send out demand letters and lawsuits.
If you don’t know if you meet all the guidelines, then the garbage lawyers think, “Well, if nobody knows, we may as well run an automated scan and send out a demand letter arguing they’re inaccessible — they’ll probably settle because it’s not worth it for them to defend against the lawsuit.”
Granted, there are gray areas to website accessibility but we need to make bullet points under the law as binary as possible:
Do you meet X requirement? Yes or no.
Do you meet Y requirement? Yes or no.
How Lawmakers Should View WCAG
WCAG should be viewed by lawmakers as a beautiful, unexpected Amazon box of time-saving bounty; a gift from Geek Gods.
It’s almost as if this international community of accessibility developers came together and did 94% of the dirty work.
Oh wait, that’s actually what happened.
And now all that’s left to do is to read through it, edit it, make it easier to understand, take some things out, put some things in, and make it fit for mass consumption.
But so far the governing bodies that have published recent accessibility law aren’t even doing that; they’re being extremely lazy and just accepting a bunch of organized but winding jargon, rubber stamping it as good to go, and throwing it onto the public.
And this is no good because, as I mentioned above, WCAG isn’t easy to implement — especially WCAG 2.1 — and a handful of the success criteria aren’t easy to test (know definitively whether your website meets them or not).
WCAG version 2.1 was released in July of 2018 and was quite ill-timed.
Picture this, you’ve got this little baby dear not unlike Bambi, trying to pick herself up on shaky legs so she can trot off to her mom after falling down and getting separated from her pack.
Just as Bambi makes it to one knee, an avalanche cascades on top of her, burying her under 48 feet of snow and ice.
Bambi signifies the entities (businesses, non-profits, companies, corporations, governments, etc.) starting to come to terms with 2.0, attempting to implement the core principles.
The avalanche comes when the W3C decides, okay let’s throw 2.1 out there to really spice up life.
2.1 has less success criteria but is more technically complex, difficult to check for, and created confusion as to whether 2.0 was still good or whether to just use 2.1; it really threw a lot of people off scent of the accessibility trail.
It’s very telling how many guides that are already out there (including my own) to help people understand the guidelines put forth by the WAI of the W3C.
It’s also very telling that I can go to web accessibility agency websites and technically light up the scoreboard with elements or weak spots that run afoul of WCAG 2.0 and especially 2.1.
Read: Even the experts and specialists can’t technically meet all of the guidelines!
It doesn’t mean their websites are inaccessible, it means WCAG is hard to follow.
Again, this tells you WCAG is NOT easy to read and understand and/or implement.
That’s not a problem. That’s a huge problem.
Advocacy & Practicality
The reality of the web accessibility situation is people don’t know what’s going on; they are confused, flustered, and trying to maintain face while panicking beneath the surface.
Sure, the directly affected entities (companies, individuals, small businesses, non-profits, state, local, and federal governments, etc.) are included in this but I’m more so thinking of judges and lawmakers here.
They’re completely buffaloed by web accessibility and thus we see a constant referencing to somewhere else (e.g. WCAG, Section 508, the DOJ’s referencing of WCAG, etc.) when they talk about web accessibility and what is required.
They understandably don’t get this stuff.
It took me over 200 hours of concentrated research to understand the landscape, so believe me, their lack of knowledge isn’t what I take exception to.
My main critique is don’t require of others that which you, yourself, do not understand.
Instead of jumping to the conclusion that we should already have these web standards in place because an organization thought to create them, how about we look through them first?
Maybe there’s a better approach than just running with the only one that’s presented?
Putting Web Accessibility In Perspective
Think of our collective web accessibility performance on a scale of 0–100.
The web had existed at 1–2 until 2016, was 3–4 by 2017, 4–5 in 2018 and now all of a sudden accessibility has emerged to the forefront and we’re all supposed to be operating at 96+.
Evolution can be accelerated but not that fast.
Just look at how far we’ve come with web design. Take a look at the ESPN.com homepage from 1999:
And now take a look at ESPN.com from today, in 2019:
Web design didn’t just flip a switch to improve and become vastly more sophisticated overnight. It took years of constant tinkering and innovation to look better, load faster, become responsive on mobile devices, etc.
Similarly, we can’t just suddenly decide that accessibility is a priority and expect millions of websites to be fully accessible within four months.
Beyond a lack of talent, knowledge, and skills in the marketplace, making content accessible takes time.
Let me emphasize that again: It takes time.
Even if you pay 5-figures for an agency that specializes in website accessibility remediation to retrofit your website, it can still take them 3–4 months to make your website fully accessible.
That’s a reality. And, no, there is NO AI solution that can automatically fix everything in minutes, hours, or days.
Saying that accessibility takes time does not diminish the importance of making the web accessible.
And it isn’t incongruent with advocacy.
Rather, addressing basic accessibility first is a pragmatic push towards ultimately realizing an accessible web.
Because people can understand the basics.
People can implement the basics.
People can then build upon the basics.
And because the basics make a huge impact in improving how persons with disabilities interact with websites and apps and access content.
But if we say, “Your website needs to meet all the success criteria under WCAG 2.0 and 2.1 AA and it already needs to be done so do it now because you’re already in violation,” well, that doesn’t accomplish anything besides a transfer of wealth to plaintiff’s lawyers.
It costs a lot of time and money to technically meet all of the success criteria in WCAG. Enough that it can actually shut down smaller businesses — or at least their websites.
No matter how important the issue (and web accessibility is enormously important), you must lay the proper groundwork first.
You can’t skip building a strong foundation if you want to be successful in any endeavor.
Alternative to WCAG
Okay, so you’re starting to see my point.
But what’s the solution?
The Web Accessibility Standards (WAS).
This is my current project. Here are my self-imposed criteria:
- Must be in written in plain, easy to understand English
- Must include the most critical components to web accessibility
- Has to be at least 80% binary (yes/no) requirements
- Must be no longer than four Word document pages
WAS will largely be a distillation and simplification of WCAG 2.0 AA but it will be unique; it will have certain requirements that WCAG does not have and vice versa.
Update: The Web Accessibility Standards (WAS) have been published. The following PDFs are available in both light and dark foreground options:
To learn more about the Web Accessibility Standards, become a fan of mine on Medium or subscribe to the free newsletter on ADABook.com.