Re: CfC: Issue 122

I just re-read and noticed the  “ignore the other SC for awhile”

this should never be done.   The SC were written to work as a set.    No SC should be looked at  except as part of the whole set.

Also - looking at techniques and SC together should not be done to determine WCAG coverage.

WCAG SC is what must be true.     All else is advisory or informative.

best


Gregg



> On Dec 14, 2015, at 12:32 PM, 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 Tuesday, 15 December 2015 16:46:15 UTC