WCAG 2.1 Is the Current Standard, Not WCAG 2.0 — and WCAG 2.2 Is Coming
The title kind of says it all.
WCAG 2.1 has been the standard for over two years — it was published in June 2018.
If you rewind to when the Accessibility Guidelines Working Group (AGWG) was asking for feedback on its near-final 2.1 draft, many of the Success Criteria in WCAG 2.1 are effectively three years old. Though you could argue only 2½ years if you go by the April 2018 Proposed Recommendation date.
If your software development life cycle is under 3 years (I really hope so) then you have no excuse for not integrating WCAG 2.1 Success Criteria into your projects, even if you are still struggling to sort them out.
If the third-party tools (libraries, frameworks, resets, etc.) on which you rely are not honoring WCAG 2.1 then you should file bugs or, better yet, find new tools. You are the one at risk, not them. At least not until the industry as a whole threatens to move away from these non-conforming tools.
Looking at the larger timeline for WCAG we can spot a trend.
WCAG 1.0 was released in 1999, WCAG 2.0 came out in 2008, and WCAG 2.1 in 2018. It’s not like any of these snuck up on you.
Consider the common tools in use today and how young they are compared to WCAG:
2005 – Prototype
2007 – MooTools
2006 – jQuery
2006 – Sass (no scss)
2006 – YUI
2009 – OOCSS
2006 – SCSS
2011 – SMACSS
2011 – Bootstrap
2011 – Grunt
2012 – BEM
2012 – Webpack
2013 – React
2013 – Gulp
2015 – Babel
2015 – CSS Modules
2016 – Styled Components
2016 – Create React App
What framework do you use? WCAG is older. What library do you use? WCAG is older. What content management system do you use? WCAG is older. What intern do you use? WCAG is (probably) older. And so on…
There is no reason not to have expected updates to WCAG. If anything, having 10 years between releases was an opportunity to figure it out and account for it into your process. Not to get complacent.
Claiming as an organization that you have chosen not to adopt WCAG 2.1 also does not protect you. A user can file a complaint regardless, and making a conscious decision to ignore the current standard will not absolve your failure to implement it.
If I get pulled over for blowing off a stop sign, I can’t claim that since it only went up two years ago I haven’t had time to prepare. It doesn’t matter that my car is three years old and I did not account for braking at that intersection in my Total Cost of Ownership when I purchased it.
Alternately, I cannot tell the same officer (later that day, I presume) that I am disregarding the 25 miles-per-hour school speed limit simply because I have made a business decision to maintain 40 miles-per-hour so my velocity will still be up going into my next sprint, er, intersection.
By the way, WCAG 2.2 is coming.
If it follows the 2.1 update cadence, you can expect it in under a year (mid-2021). You have enough warning to put it on your roadmap, excise it from backlog, make it a part of your strategy.
WCAG 3.0 is under active development as well.
Get your house in order, because your users don’t care about your excuses.
So, in circa 2017, when Section 508 (in the USA) was FINALLY getting to the “refresh” deployment phase, the new regs were “harmonized” with WCAG 2.0. I remember on a webinar with the US Access Board someone asked if the regs would “automatically” update to WCAG 2.1 which, as I recall, were in the development phase. The blank answer was ‘Section 508 is harmonized with WCAG 2.0’ (period). Emphasis on the period. I heard a similar question asked recently during a webinar, this time as to whether WCAG 2.2 would be the guidance. The same blank response was heard.
Such is life.
Thank you for your blog, Adrian. I always enjoy reading your stuff.
John, thanks. I think Section 508 is a good, yet unfortunate, example. For laws that cite 2.0 specifically, the transition to WCAG 3.0 will likely be just as painful as the 2.0 update.
It took a full decade to update Section 508 to incorporate WCAG 2.0. I spent several years on the advisory committee defining the updates and then watched it take another several years to be finalized (to something quite different than the committee proposed). Do not anticipate Section 508 being updated any time soon – or perhaps ever. The reality is that Section 508 is irrelevant to the vast, vast majority of the web. We barely even mention it any more in our trainings.
I would like to mention same thing for AODA as Section 508, about specific WCAG 2.0 guidelines.
Thanks Adrian for all your blogs, it has been very informative.
The only problem with this is that the definitions and requirements in WCAG2.x are so vague and broad that they are impossible to meet without tripling the amount of code required and significantly reducing usability for the vast majority of users.
Not to mention that the spec itself is so ridiculously convoluted and full of jargon that it’s difficult for college educated developers to understand, much less the “cognitively challenged.”
I have been an advocate for accessibility for years, understanding that the spirit of the law is more important than the letter and that there’s plenty of gray area in between. WCAG has turned that into a completely legalistic exercise in frustration for me as a developer and UI/UX professional.
The current spec appears to have been written for the sole benefit of ambulance-chasing lawyers.
Disliking WCAG, or its language, does not mean you can ignore it.
There is broad agreement that meeting WCAG does not guarantee accessibility; meeting WCAG only signals a baseline, minimum effort.
I doubt I can convince you that WCAG is for anyone other than amoral lawyers (nor is that my job). I can, however, point you to WCAG Success Criteria that have machine-testable outcomes (such as text contrast and missing media alternatives). While those are only useful for ~30% of SCs, they also tend to correspond to the biggest accessibility barriers.
But as you note, humans will always be needed to make both accessible and usable experiences.