Re: CfC: Issue 122

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 18:33:18 UTC