Re: WCAG 2.2 - tightened requirements approach

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.

Being backward compatible relates to a site that conforms to WCAG 2.2 – if a site conforms to 2.2 then it conforms to 2.1 and 2.0. If that site doesn’t conform to 2.2 then it MAY conform to 2.1 or 2.0 but you’d need to look more carefully at what SC did pass, or even what parts of a modified SC that passed.
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.
Yes, this is a very important point. There would effectively be versions for individual SC (hopefully not many).

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.

Good point to keep in mind.
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.
I think that your option 4 is the same as option 1 – Alastair detailed it as 2.4.11 in his email. Can you confirm that this is what you are talking about?

AWK


On Fri, Jun 28, 2019 at 6:28 PM Léonie Watson <lw@tetralogical.com<mailto: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
[cid:BCBD7D4B-677E-4B95-AE3F-60005DBD9EE4]