Re: WCAG 2.2 - tightened requirements approach

Hi Wilco,
> let's say you've tested SC 2.4.7 in a WCAG 2.2 audit and the outcome is "not satisfied". You can no longer infer from that whether or not that page does conform to WCAG 2.1 or 2.0.
That isn’t how we’ve talked about backwards compatibility previously, the main scenario was: If you pass WCAG 2.2 you automatically pass 2.1 / 2.0.
The 1st bullet in the requirements<https://raw.githack.com/w3c/wcag/master/requirements/22/index.html> is:

  *   Web pages which conform to WCAG 2.2 conform to WCAG 2.1 (which conforms to WCAG 2.0).
And then:
“Existing success criteria may be modified or removed in a WCAG 2.x release, but the resulting change must retain functional backwards compatibility with previous versions. That is, accessibility requirements in WCAG 2.0 will still be covered by WCAG 2.x.”

> The SC number would no longer be useful as an identifier for SCs. We've all gotten used to thinking of 1.3.1 or 4.1.2. After a change like this, we'll have to specify, 2.4.7 for WCAG 2.1 or for WCAG 2.2. We'll have to include this into our database schemas and data formats too. All of that is problematic.
Ok, so there’s a downside. How big a thing is that, compared to deprecating 2.4.7 and having a new 2.4.x?

> Proposing option 4: We could have the SC from option 3, but with a new number. We would deprecate SC 2.4.7 as it is superseded by this new SC.
Interesting, that would prevent overlap at least.
Would you think the previous SC should appear at all in the spec (with a deprecated warning message), or just remove it entirely?
Also, given that we have the same Understanding docs, presumably we’d keep the previous one for 2.4.7 as a stub and link to the new one.

Cheers,

-Alastair