Kilian Valkhof

WCAG 2 is what we have

Last week, I got tagged twice in a Twitter thread about the new APCA color contrast algorithm, asking my opinion and when it was gonna appear in Polypane (it will). APCA has a lot of developers and designers excited, because its a much more thorough algorithm for color contrast compared to the algorithm currently in WCAG 2.

It feels good to see such enthusiasm about an accessibility topic. APCA is exciting because it tends to produce results that look better to most people’s eyes. But you’ll see many people, including me, pushing back on using it now. It’s not because we don’t want more people engaged in accessibility, or because we think APCA is bad and WCAG2 is good and never changing. It’s because WCAG 2 is what we have.

WCAG moves slow. Very slow. Frustratingly slow. But that’s what the process needs. Accessibility is a complex topic, and WCAG requires consensus. Of course there are things to disagree with in WCAG2, or that are unclear and obtuse. But, for better or worse, WCAG 2 is the rulebook we use.

It’s important to have this rulebook, because ask 10 accessibility auditors their opinion and you’ll get 10 different opinions. This is good, because “being accessible” is not a uniform something. What’s accessible to me is maybe not accessible to you, and WCAG brings a guidebook that we can use to verify accessibility in an, if not 100% objective, at least consistent way.

That’s also why for example the EU Accessibility Act references WCAG2.1 as the rulebook to use. It’s extensive, well-tested and a wide array of organizations agreed on it. (I realize I’m using a roundabout way of saying it’s a standard, but on the web something can be a standard with zero people actually interested in implementing it.)

The current version of WCAG is 2.1. WCAG 2.2 is coming next year after a fairly long time, and only years later will WCAG3 see the light of day. WCAG 3 is not ready yet, as Eric Eggert says.

Whatever is currently written down as WCAG3, including APCA, is subject to change. This is great! It means developers still have a chance to submit feedback. If you like something, don’t like something, or have suggestions: now is the time.

It also means that whatever is written down as WCAG3 at the moment, is not something you should base your accessibility choices on. Worse, using these guidelines while they’re not ready might lead to you thinking you’re doing the right thing while not conforming to WCAG2, and you’ll have to change it.

Accessibility is already an uphill battle and seeing people bristle at the prospect of having to explain that “yes these guidelines will probably end up being the ones to use, but right now we have to use these guidelines” is not surprising. The job of an auditor is hard. Having people care about and taking accessibility rules into account when implementing is amazing, but when they’re not the accessibility rules their products will actually be checked against it will be frustrating for both the auditor and implementer, even though they both work towards a common goal: making the product more accessible.

It’s clear that WCAG 3 is the future, but what WCAG 3 is is not clear yet and won’t be clear for years to come. Anything that’s currently part of the draft is not based on consensus (yet) and can change at any moment. That’s not something you want to use.

Right now, WCAG 2 is what we have, and there are tons and tons of resources on using it well. So let’s make good use of it.