Re: WCAG 2.2 - tightened requirements approach

Hey Alastair,

Even small changes to existing things can have substantial downstream
effects. Case and point, the IDs of success criteria changed between WCAG
2.0 and 2.1. This has caused a number of problems. The quickref now needs
to account for the same SC having multiple success criteria. And tools that
use RDF for reporting, such as the WCAG-EM Report Tool, are now going to
need to maintain mappings between different versions of WCAG. That's just
not a great use of time, and could have been avoided.

The world has been building tools for WCAG 2 for 11 years. For WCAG 2.1
we've all had to figure out how we're going to add success criteria. Most
tools have this capability at this point. Deprecating something just means
removing it, that should be fairly straight forward for anyone. Changing an
SC however is a far more substantial change. For Deque, it would likely
require architectural changes to several of our products. I imagine it's
the same thing for others. It's something I'd like to avoid if we can.

As for how you'd present a deprecated success criterion. My suggestion
would be to include the number and descriptor, but hide the text behind a
"deprecated. This criterion has been superseded by X.Y.Z. See text" type of
button. Just so that there isn't a gap in numbering and it's clear what
happened.




On Mon, Jul 1, 2019 at 12:20 PM Alastair Campbell <acampbell@nomensa.com>
wrote:

> 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
>


-- 
*Wilco Fiers*
Axe product owner - Co-facilitator WCAG-ACT - Chair ACT-R / Auto-WCAG