It’s charter time for the Accessibility Guidelines Working Group, well, in 6 months, but we have to start the planning well in advance!

The charter (see the last charter) defines what we work on, and to some degree how we work on it. A question the group is considering is what approach to take to the next 2 years of work.

In the last charter we agreed to go full-steam ahead on WCAG3, an overhaul of the guidelines. That’s going reasonably well, and we’re tracking the plan.

A question has been raised though: Should we be incrementally updating WCAG 2 instead?

The question of starting point came up before our last charter point, I have a strong opinion on it, but I didn’t have these points written down from then.

I have to take my “chair hat” off here, this is my personal opinion. The following points may influence other people (kinda the point of writing them down), but as chair I’ll go with the group’s decision.

I think that overhauling WCAG is necessary for the next version, not just to meet our goals, but there are several practical advantages compared to iterating on WCAG 2.

There are several options in the group discussion, but I’m focusing on whether we overhaul the whole thing, or go bit by bit from WCAG 2.

The concerns I have with an incremental approach from WCAG 2 are:

Cascade effect

Criteria in WCAG 2 have adjacent scopes, some even overlap in scope, therefore replacing some will cascade the re-writing across criteria.

Definitions also cascade across normative and non-normative text. Change a definition, the scope of all the criteria which use it can potentially change. A key definition that almost everyone wants to replace is “web page”, which really doesn’t work in some important scenarios. It’s used explicitly in 11 criteria, and ‘conforming alternate version’, where the alternative has to be available from the page. If that changes, many things change across the spec.

A proposed addition to WCAG 2 is the concept (from WCAG 3) of assertions. Doing so would need some sort of system to integrate it into conformance, otherwise it’s just extra content for people to ignore.

I’m not really sure how that could work in a WCAG 2.0 context, as the current model is pass/fail for each provision. Individual assertions were not something WCAG 3 was going to require by default (they would score towards a higher level of conformance).

A lot of the difficulty we had when updating to WCAG 2.1 and 2.2 was not being able to change the pre-existing text. We had to slot things into the current structure without changing other things. Therefore we had very careful additions only, with almost no changes to the existing text.

Overall, every change is likely to trigger other changes and take longer.

Repeated re-writing

Something I’ve learned from large website re-structuring projects is that re-structuring means re-writing. Often people want to “lift and shift”, but when the content connects to each other, relies on certain things, it all needs review and revision.

I have a strong feel that cross-checking the whole at each increment is probably more work than doing it once across a fresh version. At least with a fresh version you can make lots of changes quickly as it is pre-publication.

Publication overhead

Assuming we wanted the incremental version to get to where the overhaul is going, it would take longer simply due to publication timescales. Publishing to a recommendation is around 6 months if there are no major objections or hold-ups.

I appreciate the W3C’s thorough process, but for a spec that is used as one-whole thing (rather than modules), it does incentivize larger publications.

Local maxima problem

Sometimes you have to move through a design, past where it gets worse, to get to the better design. This concept is the “local maxima”, probably an old concept but I noticed it in metrics-driven design by Joshua Porter.

I worry that patching in concepts from WCAG 3 into WCAG 2 would fall into that trough, adding complexity without as much benefit.

Marketing

Part of the success of WCAG 2 is that it has been referenced around the world by various laws, regulations, and legal cases. Those processes run even more slowly than the standards process. Getting them to move onto a (backwards incompatible) new version will take a lot. It needs to be a big push to an obviously better new thing.

An incremental update (that isn’t simply a backwards compatible addition) is a difficult sell. It adds friction without the benefit of a new approach. From previous experience, legislators tend to wait for the next big thing.