Back in 2020 I wrote about What to Expect From WCAG 2.2. At the time, the W3C’s Accessibility Guidelines Working Group was expecting WCAG 2.2 to be finalized in June of 2021. That didn’t exactly work out. We’re currently looking at September 2022 as a potential date for WCAG 2.2. That’s a significant delay. So it’s worth asking the question, how come writing WCAG 2 takes so much time, and why do we see such lengthy delays?
One in a million exceptions
Firstly, getting it right just takes a lot of time and effort. WCAG 2 is used throughout the world as the standard for accessibility of websites and documents. It is used for mobile and desktop apps too, even though it isn’t strictly designed for that. The number of organizations that are either contractually or legally obligated to conform to WCAG seems to be growing larger every day.
Because WCAG 2 is applied to many billions of web pages, even something that happens once in a million pages has to be considered. One such example came up in the development of the 3.3.7 accessible authentication criterion. Some sites with high security needs include object recognition tests when you log in with an unknown device. For example, you may be prompted to view a list of pictures and select which ones have cars in them.
Finding the right wording for such an exception is complicated. We don’t want to make it too broad– that would defeat the purpose of having a requirement at all. Yet we needed something, since we don’t want accessibility to come at the cost of security. Finding a middle ground that was acceptable to everyone involved took months to determine.
Focus Appearance
The most hotly contested success criterion of WCAG 2.2 proved to be 2.4.11 focus appearance. This is easily the most complicated success criterion ever written for WCAG. Here the challenge proved to be ensuring the success criterion be strict enough to make a meaningful difference, without being so prescriptive that it would limit different designs of focus indicators.
There are a lot of different ways to indicate which element on the page has focus. Drawing a thin rectangle around the focusable element is by far the most common. Other solutions include having a thicker bar on the edge of a component, changing the background color, moving the component, putting a glow-effect around the component, etc. Describing how to do all of those, in components of varying sizes and shapes, and ensuring all scenarios results in a clear focus indicator that isn’t unreasonably large, meant going through dozens of iterations of the success criterion.
Striking a good balance on focus appearance proved very time consuming. Even getting as far as we did, there are still reasons to be critical. For example, a criterion this complex is going to be difficult to teach. That can make it difficult to implement without mistakes. It is also not something that can be tested fully automatically, and human testing as always is costly.
There is also the consideration of what role browsers should play in ensuring good focus appearance. By default, the browser decides the color, size, and shape of the focus indicator. Those often don’t meet the requirements, and so W3C decided to make content authors override the poor defaults created in the browser. Even Chrome and Edge’s accessible focus indicator is not permitted under the success criterion, since the criterion requires the focus indicator to be persistent.
Substantial Feedback
The amount of feedback that the W3C received on WCAG 2.2 was significant. On WCAG 2.2 alone, almost 350 issues were raised. That’s not quite the almost-700 issues that the W3C got up to in developing WCAG 2.1, but that is the final number, and WCAG 2.2 still has to go through two more stages of the W3C process. Each issue then has to be discussed, an answer has to be written, and many of them involve updating one or more documents. It all adds up.
Writing web standards is not like creating software. If there is a bug in the standard, once that standard is a recommendation it is there forever. Even on subsequent versions, because of how disruptive changes to existing criteria can be, we’ve so far only ever added new success criteria. The few updates that were ever done are editorial in nature. Because of how difficult it is to fix issues in the future, the W3C has to move slowly and with great care.
WCAG 3.0
While development of WCAG 2.2 is done largely separate from WCAG 3.0, the delay of one has certainly impacted the other. In 2021, the W3C had to split its time between the two standards. Working on two standards simultaneously slowed down both efforts significantly, and we ended up having to do a lot more context switching than we wanted to. Those of you keeping track may also have noticed WCAG 3.0 isn’t progressing at a particularly fast pace either.
So, September?
The W3C is currently looking to make WCAG 2.2 a recommendation in September 2022. There is a lot of work left between now and then. It’s good to have goals, but this work is often unpredictable. I would personally not be surprised to see that slip by a few more months, but at the stage we are at today, finalizing WCAG 2.2 before the end of the year seems likely.
An updated version of our What to expect from WCAG 2.2 will come out as soon as we’re confident about the release date.
