RE: WCAG 2.2 - tightened requirements approach

  *   Either way you’d have to test with & without the new requirements.

I think this will be the majority case as most content is not fully conformant today – so I’d expect most content to not fully conform to 2.2 and for that reason most folks will want to see their level of conformance to 2.1 or 2.0 as fallback.  So testers will need to test for each variation and record the results.  So we need an approach that facilitates folks doing that.  So even if we were to modify 2.4.7 testers would still need to test the different versions of it and that is why I think it is more clear to have different versions of the SC that build on each other to help enforce that.  At some point the more limited SC could be deprecated in the future.  Deprecation today would be better than a modified SC because if the tester selected WCAG 2.0, 2.1 and 2.2 as the set of tests then they would get 2.4.7 to test from 2.0 and 2.1 but not 2.2 – so it would be evaluated by the tester.

Jonathan

From: Alastair Campbell <acampbell@nomensa.com>
Sent: Tuesday, July 2, 2019 9:16 AM
To: Andrew Kirkpatrick <akirkpat@adobe.com>; Jonathan Avila <jon.avila@levelaccess.com>
Cc: WCAG <w3c-wai-gl@w3.org>
Subject: Re: WCAG 2.2 - tightened requirements approach

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Andrew wrote:
> 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?

In my original email option 1 was simply adding an SC, not changing the original (except perhaps the level, as part of option 2).

The difference for option 4 would be that the current SC would be marked as deprecated in some way (or even deleted from the spec?). I put an example in my email earlier today.


Jon Avila wrote:
>People may be testing against 2.2 but may not meet 2.2 and then want to know how they conform with 2.1 or 2.0.

I don’t think we can automate that. In any case you’d have to test for different requirements to have an answer to both 2.1 & 2.2.


  *   If there is a separate SC then you’d have to test an extra set of requirements on top of focus-visible in a separate SC.
  *   If there is a modified SC then you’d have to test an extra set of requirements on top of focus-visible from the 2.1 SC.

Either way you’d have to test with & without the new requirements.

However, if you are just interested in 2.2 (or just 2.1) then having a modified SC is easier.
Similarly, having 2.4.7 clearly marked as deprecated in 2.2 is easier, if slightly cluttered.

Cheers,

-Alastair