Re: WCAG 2.2 - tightened requirements approach

Hi Alastair,

At issue is that we have one complete collection of requirements, but some
of that collection is built on top of prior requirements. Deprecating a SC
at one version that isn't deprecated at the prior version will I suspect
also introduce confusion: is it deprecated or not?

If however it is 'superceded' by the newer SC, then you will still be
hitting the old SC when you hit the newer (better) SC. I am not seeing an
advantage to deprecation here.

JF

On Mon, Jul 1, 2019 at 11:14 AM Alastair Campbell <acampbell@nomensa.com>
wrote:

> Hi John,
>
>
>
> > I'd favor adding a new SC and new SC number, but I'd avoid out-right
> deprecation at this time: we instead could note that the new Success
> Criteria supersedes SC 2.4.7.
>
>
>
> Surely having two separate SCs for (essentially) one requirement is going
> to be confusing?
>
>
>
> If there are two requirements, they stack up like this:
>
>    - Have a visible focus indicator.
>    - Have a visible focus indicator that meets these contrast & size
>    criteria.
>
>
>
> So taking on Wilco’s suggestion I think the better options are:
>
>
>
> -          Add a separate SC at level AA (e.g. Enhanced keyboard focus),
> and move 2.4.7 to level A;
>
> -          Modify 2.4.7 to include the new requirements.
>
> -          Add a separate SC at level AA and deprecate 2.4.7.
>
>
>
> Of those, my least favourite is having two separate SCs, one at A and one
> at AA.
>
>
>
> Wilco’s suggestion has most of the advantages of modifying the current SC *so
> long as* we mark 2.4.7 as deprecated (or remove/hide it altogether).
>
>
>
> If we don’t mark 2.4.7 as deprecated then the other options look better
> from an understandability point of view.
>
>
>
> -Alastair
>
>
>


-- 
*​John Foliot* | Principal Accessibility Strategist | W3C AC Representative
Deque Systems - Accessibility for Good
deque.com