Re: WCAG 2.2 - tightened requirements approach

Hey all,

It seems to me that option 2 and 3 are breaking changes, and so they're not
really available to us. Here's why:

*Option 3* I think it would make WCAG 2.2 not backward compatible with 2.0
/ 2.1. To illustrate that, 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. The issue might
be from the new part, or the old. For WCAG 2.2 to be backward compatible,
it has to be a superset of WCAG 2.0 and 2.1, and with a change in an SC, it
that's no longer the case.

Similarly if you satisfied SC 2.4.7 in a WCAG 2.1 audit, you can't tell
whether or not you satisfied it in WCAG 2.2. You need to test it again, and
treat WCAG 2.2's version of 2.4.7 as a different SC from WCAG 2.1 and 2.0.
If you're storing your results in any database, you'll need to track it
differently too. 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.

*Option 2* I would also consider to be a breaking change, although one with
fewer side effects. Changing the level of an SC from WCAG 2.1 to 2.2 will
require most of us to update how our tools / reporters work. The problem
with that is that unless you know for sure that the audience of a report is
only interested in one particular version of WCAG, you're going to have to
now include both levels and the version in which it changes into your
report. You can no longer group results by level, which is something quite
a few tools do. All of this is just going to get confusing.

While *option 1* seems OK to me, I think there's an alternative not
mentioned yet.

*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.
This would avoid all of the above problems. Deprecation is a well
understood mechanism, and has been used in W3C recommendations in the past.
If we're changing the text of an SC, it's effectively a new requirement.
Most people will have to treat it as a new requirement. If they don't,
mistakes happen. The solution we decide on should help them understand this.

Kind regards,

Wilco


On Fri, Jun 28, 2019 at 6:28 PM Léonie Watson <lw@tetralogical.com> wrote:

>
> On 28/06/2019 17:01, Patrick H. Lauke wrote:
> > My personal preference would be to patch in tighter requirements
> > directly on the SC itself, instead of having to do weird extra-specific
> > SCs that overlap almost entirely except for one or two
> > clarifications/tightenings (provided we can resolve the possible
> > understanding/techniques doc mismatch, as already discussed in this
> thread)
>
> Emphatic +1 to this.
>
> >
> > P
>
> --
> @TetraLogical TetraLogical.com
>
>

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