Re: CfC: Issue 122

Hello Andrew,
I am fine with the stated consensus position stated in your email dated Dec 11.
I believe no change is required to WCAG 2 SCs for the issues raised.
If  taken up for an extension-related discussion, my email above
attempted to explain why this may not be needed unless the posers in
that email are also going to be debated upon.
Thanks and best wishes,
Sailesh Panchang
Phone 703-225-0380 ext 105
Mobile 571-344-1765

On 12/14/15, Andrew Kirkpatrick <akirkpat@adobe.com> wrote:
> Sailesh,
> To get the clean and clear answer to the CfC - do you agree with the
> proposed response?
>
> Thanks,
> AWK
>
> Andrew Kirkpatrick
> Group Product Manager, Accessibility
> Adobe
>
> akirkpat@adobe.com
> http://twitter.com/awkawk
> http://blogs.adobe.com/accessibility
>
>
>
>
>
>
>
>
> On 12/14/15, 13:32, "Sailesh Panchang" <sailesh.panchang@deque.com> wrote:
>
>>Really, I do not think there is a need for any SC or an extension
>>that will require or mandate  that  one  MUST use explicitly
>>associated labels.
>>When a label is explicitly / implicitly associated, clicking it has
>>moved focus to the corresponding control. This is a UA feature that
>>aids accessibility and documented in H44.
>>So when a visible text label is present, accessibility advocates /
>>consultants should urge developers to use the most appropriate
>>technique  that helps  conform to all applicable SCs and helps the
>>widest group of PWDs.
>>Now one can  rely on the minimum level as someone suggested in a
>>previous thread and claim conformance with
>><p><input type="checkbox" title="send me a ton of email" />Send me a
>>ton of email</p>
>>but accessibility consultants must highlight the demerits of this
>>technique and educate developers to use the right technique in the
>>circumstances.
>>
>>If a custom control is used for which H44 cannot be used, and the
>>control is labelled with aria-labelledby, will WCAG2  similarly
>>require clickability of that label too? Will the UA need to implement
>>this or will it become the duty of the developer?
>>
>>Compare this to SC 2.4.1. Ignore other  SCs (like Level AA 2.4.7) and
>>other sufficient techniques for the moment, if a skip link is used to
>>claim conformance,  the link needs to be visible / become visible on
>>tab focus. The SC does not require the link to become visible. But,
>>the test procedures for G1, G123, and G124 all require that the link
>>either always be visible or be visible when the link acquires focus.
>>Not doing so amounts to incorrect implementation of the technique and
>>one cannot rely on that technique to claim conformance to SC 2.4.1. So
>>should this "visibility" of the mechanism be written into SC 2.4.1? I
>>think not.
>>Sure one can use other techniques like headings and landmarks, but
>>again,  consultants need to point out that these will not help sighted
>>keyboard-only users when one needs to install a plugin to make it work
>>and they are not available for all browsers / do not work reliably.
>>
>>Best wishes,
>>Sailesh Panchang
>>
>>
>>On 12/12/15, Detlev Fischer <detlev.fischer@testkreis.de> wrote:
>>> Agree with Laura. (and thanks to Paul for bringing it up). We should
>>> revisit
>>> the issue in an extension.
>>> Detlev
>>>
>>> Sent from phone
>>>
>>> Sent from phone
>>>
>>>> Am 11.12.2015 um 17:59 schrieb Laura Carlson
>>>> <laura.lee.carlson@gmail.com>:
>>>>
>>>> +1
>>>>
>>>> If I had been around at the time, I would have certainly voted for
>>>> requiring WCAG 2.0 to require that check boxes and radio buttons have
>>>> clickable labels. It is a pity that it doesn't. Revisiting this in an
>>>> extension spec and WCAG.next is a good idea.
>>>>
>>>> Kindest Regards,
>>>> Laura
>>>>
>>>>> On 12/11/15, Andrew Kirkpatrick <akirkpat@adobe.com> wrote:
>>>>> CALL FOR CONSENSUS – ends Tuesday December 15 at 11:30am Boston time.
>>>>>
>>>>> Related to Issue 122 in GitHub[1] we believe that the discussion has
>>>>> wide-ranging and productive, but at this point think that we have
>>>>> heard
>>>>> all
>>>>> of the arguments [2][3] and that a consensus opinion has emerged.
>>>>>
>>>>> The specific question in the GitHub issue is "Please clarify that
>>>>> WCAG's
>>>>> Info & Relationships SC requires that checkboxes and radio buttons
>>>>> have
>>>>> clickable labels, i.e. programmatic "relationship" associations and a
>>>>> title
>>>>> alone will not suffice”
>>>>>
>>>>> The proposed consensus view is that WCAG 2.0 does not require that
>>>>> checkboxes and radio buttons have clickable labels.  The Working Group
>>>>> agrees that there is utility for end users when the labels for these
>>>>> (and
>>>>> other) controls are clickable, but there are no success criteria that
>>>>> make
>>>>> this specific requirement.
>>>>>
>>>>> Related to this question is whether the page content used as the
>>>>> visible
>>>>> label for the control (in order to meet SC 3.3.2) must be explicitly
>>>>> associated with the control that is being labeled. The proposed
>>>>> consensus
>>>>> view is that the relationship between a control and the content used
>>>>> to
>>>>> label that control may be made implicitly as well as explicitly, and
>>>>> what
>>>>> will really dictate whether SC 1.3.1 (as well as SC 4.1.2) is met is
>>>>> whether
>>>>> the assistive technologies used in the site’s conformance claim are
>>>>> able
>>>>> to
>>>>> provide support for the implicit or explicit relationships provided in
>>>>> the
>>>>> markup. An explicit markup relationship (e.g. Using the HTML for and
>>>>> id
>>>>> attributes to make the association or by enclosing the input within
>>>>> the
>>>>> label element) is preferred as it will increase the likelihood that
>>>>> user
>>>>> agents will support the design pattern and will simplify testing, but
>>>>> implicit relationships may also be supported and as a result may
>>>>> satisfy
>>>>> WCAG 2.0 success criteria.
>>>>>
>>>>> The working group agrees that there is benefit to many users when they
>>>>> can
>>>>> click on a larger area for a checkbox or radio button and on some user
>>>>> agents using the label element in conjunction with an input can make
>>>>> this
>>>>> happen without any work by the page author.  Despite the benefit, this
>>>>> was
>>>>> not part of the original intent of WCAG 2.0, so the working group will
>>>>> forward this issue to the task forces that are currently working on
>>>>> extensions for WCAG 2.0 for review as a topic for consideration within
>>>>> an
>>>>> extension. In addition, this issue will be added to the “Post WCAG
>>>>> 2.0”
>>>>> wiki
>>>>> page[4] for issues that the group wants to keep a record of for
>>>>> consideration in future versions of WCAG.
>>>>>
>>>>> If you have concerns about this proposed consensus position that have
>>>>> not
>>>>> been discussed already and feel that those concerns result in you “not
>>>>> being
>>>>> able to live with” this position, please let the group know before the
>>>>> CfC
>>>>> deadline.
>>>>>
>>>>> [1] https://github.com/w3c/wcag/issues/122
>>>>> [2]
>>>>> https://lists.w3.org/Archives/Public/w3c-wai-gl/2015OctDec/0193.html
>>>>> [3]
>>>>> https://lists.w3.org/Archives/Public/w3c-wai-gl/2015OctDec/0225.html
>>>>> [4] https://www.w3.org/WAI/GL/wiki/Post_WCAG_2_Issues_Sorted
>>>>>
>>>>> Thanks,
>>>>> AWK
>>>>>
>>>>> Andrew Kirkpatrick
>>>>> Group Product Manager, Accessibility
>>>>> Adobe
>>>>>
>>>>> akirkpat@adobe.com
>>>>> http://twitter.com/awkawk
>>>>> http://blogs.adobe.com/accessibility
>>>>
>>>>
>>>> --
>>>> Laura L. Carlson
>>>
>>>
>>
>

Received on Monday, 14 December 2015 21:00:52 UTC