Re: WCAG 2.2 - tightened requirements approach

Thanks Alastair for your response.
>The problem with the term is the ‘visible’ bit. As I said previously, I don’t think we >should add requirements via a definition.
Sailesh: That's why I pointed to terms like PD or change in context
etc. used in the SC but defined in the glossary. Visible focus
indicator is no different.
If anything, 'Input Purposes for User Interface Components section',
does add a requirement, no?

> Conceptually, I think it is quite difficult to have a definition of something that only >applies to (or from) a version of the spec. I.e. why wouldn’t the definition for ‘visible >keyboard focus’ apply to every SC that uses it?
Sailesh: Your concern is valid. That's why  the definition  should be
flagged as an enhancement so the spec is backward compatible.
Maybe in a similar section like 'New Features' / 'Numbering' /
'Conformance'  in WCAG 2.1 that  was added in WCAG 2.1. And through
'Waht's new' doc.
Also the last part of the 3-part proposal: highlight it via  Understanding doc.

Respectfully and Thanks,
-- 
Sailesh Panchang
Principal Accessibility Consultant
Deque Systems Inc
381 Elden Street, Suite 2000, Herndon, VA 20170
Mobile: 571-344-1765


On 7/31/19, Alastair Campbell <acampbell@nomensa.com> wrote:
> Hi Sailesh,
>
> We discussed this in-depth during a couple of meetings, e.g:
> https://www.w3.org/2019/07/16-ag-minutes.html#item02
>
> The resolution from that was to proceed with the option that moved the
> current SC to level A, and added the new requirement as an SC at AA.
>
> Going back to your previous email:
>> Consider someone committed to WCAG 2.0 Level AA e.g. a U.S. gov agency
>> using revised Section 508.
>> Content that has focus visible today under WCAG 2.0(AA) will not pass a
>> modified SC text if the page is re-evaluated because of content changes.
>
> With the agreed approach, the pass/fail for focus-visible would be unchanged
> (apart from level), with a new requirement added at AA.
>
>
>> a. Perhaps newly defining "visible keyboard focus indicator" is another
>> way of getting it into normative requirements for WCAG 2.2 and onwards
>> without adding a new SC or changing levels. This term is undefined so
>> far.
>
> The problem with the term is the ‘visible’ bit. As I said previously, I
> don’t think we should add requirements via a definition.
>
>
>> b. The definition of what is being suggested as "enhanced focus" should be
>> included in this definition and flagged as a WCAG 2.2 entry in the
>> definition list.
>
> Conceptually, I think it is quite difficult to have a definition of
> something that only applies to (or from) a version of the spec. I.e. why
> wouldn’t the definition for ‘visible keyboard focus’ apply to every SC that
> uses it?
>
>
>> If an automated tool can test for visible focus, the additional demand of
>> WCAG 2.2 should be an add-on for WCAG 2.2 compliance only.
>
> I think that is clear in the proposed approach, there is an extra SC that
> defines the new requirement.
>
> Kind regards,
>
> -Alastair
>

Received on Wednesday, 31 July 2019 16:10:18 UTC