Re[2]: CfC: Checkbox and Radio button labels and 1.3.1

+1 to Andrew here. They are distinct and while having clickable labels 
is fine for many users, we need to be cautious about how WCAG refers to 
or attempts to mandate that kind of functionality.

My 2 cents

Josh

------ Original Message ------
From: "Andrew Kirkpatrick" <akirkpat@adobe.com>
To: "Detlev Fischer" <detlev.fischer@testkreis.de>; "David MacDonald" 
<david100@sympatico.ca>
Cc: "WCAG" <w3c-wai-gl@w3.org>
Sent: 25/11/2015 15:11:55
Subject: Re: CfC: Checkbox and Radio button labels and 1.3.1

>Detlev,
>Declaring the label to be a part of the control when they are used 
>together feels wrong to me.  The fact alone that the checkbox doesn’t 
>need the label to provide the technological functionality suggests that 
>the control is distinct from the label.  Yes, of course the best 
>practice is to use these in concert with each other, but I don’t 
>believe that we should be saying that the label is part of the control.
>
>The HTML5 spec refers to the label and the control distinctly, as does 
>the HTML 4.01 spec and at least the PDF spec.  I don’t think that we 
>should be revising the interpretation of what constitutes a control in 
>WCAG 2.0.
>
>Thanks,
>AWK
>
>Andrew Kirkpatrick
>Group Product Manager, Accessibility
>Adobe
>
>akirkpat@adobe.com
>http://twitter.com/awkawk
>http://blogs.adobe.com/accessibility
>
>From: Detlev Fischer
>Date: Tuesday, November 24, 2015 at 02:15
>To: David MacDonald
>Cc: WCAG
>Subject: Re: CfC: Checkbox and Radio button labels and 1.3.1
>Resent-From: WCAG
>Resent-Date: Tuesday, November 24, 2015 at 02:15
>
>My line would be: *If* control and label are used as a pair, these 
>items constitute parts of the same control. Where technically possible, 
>authors must then make their info relationship explicit.
>In other use cases (several checkboxes in a narrow table column), items 
>are NOT used as a pair and other means to programmatically associate 
>the label text come into play. Here, a script based technique to make 
>the label clickable makes no sense as it may apply to several controls.
>@John: This would in all likelihood not affect the normative text of 
>WCAG. It might become a Failure technique with David's proviso. We know 
>by now even Failures are 'just informative'.
>
>Sent from phone
>
>Am 24.11.2015 um 04:00 schrieb David MacDonald <david100@sympatico.ca>:
>
>>Hi Wayne
>>
>> >"label control label control label control..."
>>
>>I don't think that is what the user would experience if they were 
>>using AT. They would hear the same thing whether there is an orphan 
>>label with a redundant title on the input, or an explicit 
>>programmatically associated label. From an accessibility API 
>>perspective it is an identical experience. What is at issue is that 
>>clicking on the label sends focus into the input if the <label> tag is 
>>used, but not with other programmatically associated ways nor with 
>>aria label or title attribute...
>>
>>forcing the author to make the text clickable would outlaw 
>>aria-labelledby... unless there was a bit of JavaScript magic making 
>>the text clickable. Sounds like an opportunity to write a technique 
>>for someone!
>>
>>Cheers,
>>
>>David MacDonald
>>
>>
>>
>>CanAdaptSolutions Inc.
>>
>>Tel:  613.235.4902
>>
>>LinkedIn
>>
>>www.Can-Adapt.com
>>
>>
>>
>>   Adapting the web to all users
>>
>>             Including those with disabilities
>>
>>If you are not the intended recipient, please review our privacy 
>>policy
>>
>>On Mon, Nov 23, 2015 at 7:43 PM, Jonathan Avila 
>><jon.avila@ssbbartgroup.com> wrote:
>>>Ø  There too many ways to mess this up to depend on association 
>>>without explicit linkage or implicit inclusion.
>>>
>>>
>>>
>>>In some languages there is not a way to associate the label and form 
>>>field – without some sort of clause such as “when technology allows” 
>>>we’d risk running into an issue where WCAG would not be technology 
>>>neutral.
>>>
>>>
>>>
>>>Jonathan
>>>
>>>
>>>
>>>--
>>>Jonathan Avila
>>>Chief Accessibility Officer
>>>SSB BART Group
>>>jon.avila@ssbbartgroup.com
>>>
>>>
>>>
>>>703-637-8957 (o)
>>>Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>>>
>>>
>>>
>>>From: Wayne Dick [mailto:wayneedick@gmail.com]
>>>Sent: Monday, November 23, 2015 6:33 PM
>>>To: Laura Carlson
>>>Cc: David MacDonald; Andrew Kirkpatrick; WCAG
>>>Subject: Re: CfC: Checkbox and Radio button labels and 1.3.1
>>>
>>>
>>>
>>>I think a mechanism must exist that ensures the "label" text be 
>>>linked to the control. Proximity does not do it. If you have a 
>>>sequence of elements, not in a list and it reads "label control label 
>>>control label control..." does a program have to parse the entire 
>>>sequence to determine that labels come before their associated 
>>>controls. Is this reasonable; is it deterministic? CSS could shuffle 
>>>the order of the elements in presentation. There too many ways to 
>>>mess this up to depend on association without explicit linkage or 
>>>implicit inclusion.  So for the label element at least, I do not see 
>>>how a deterministic relationship can be guaranteed without  explicit 
>>>linkage or implicit wrapping.
>>>
>>>Wayne
>>>
>>>
>>>
>>>On Mon, Nov 23, 2015 at 11:15 AM, Laura Carlson 
>>><laura.lee.carlson@gmail.com> wrote:
>>>
>>>Hi all,
>>>
>>>+1
>>>
>>>If I had been around at the time, I too would have certainly voted 
>>>for
>>>requiring explicit clickable mechanisms. Revisiting this in an
>>>extension spec WCAG.next is a good idea.
>>>
>>>Kindest Regards,
>>>Laura
>>>
>>>On 11/22/15, David MacDonald <david100@sympatico.ca> wrote:
>>> > Andrew's response is my understanding of WCAG consensus which was 
>>>in play
>>> > during the creation of the WCAG. Personally, I would have voted for 
>>>forcing
>>> > the "click the label to select" paradigm ... but that was not the
>>> > consensus. If the title or other invisible label reports the 
>>>visible label
>>> > in a programmatic way (today via the API), I believe this was the 
>>>main
>>> > concern during the formation of the WCAG.
>>> >
>>> > I need to put aside my personal preferences in favour of being true 
>>>to what
>>> > I know was the consensus of the time, which I respect.However, I 
>>>would be
>>> > fine with revisiting this in an extension spec or even WCAG.next
>>> >
>>> > I think however, we could add a fail a missing of a visible label 
>>>on focus
>>> > but that is a separate issue.
>>> >
>>> > Cheers,
>>> >
>>> > David MacDonald
>>> >
>>> >
>>> >
>>> > *Can**Adapt* *Solutions Inc.*
>>> >
>>> > Tel:  613.235.4902
>>> >
>>> > LinkedIn <http://www.linkedin.com/in/davidmacdonald100>
>>> >
>>> > www.Can-Adapt.com
>>> >
>>> >
>>> >
>>> > *  Adapting the web to all users*
>>> > *            Including those with disabilities*
>>> >
>>> > If you are not the intended recipient, please review our privacy 
>>>policy
>>> > <http://www.davidmacd.com/disclaimer.html>
>>>
>>> >
>>> > On Sun, Nov 22, 2015 at 6:41 AM, Detlev Fischer
>>> > <detlev.fischer@testkreis.de
>>> >> wrote:
>>> >
>>> >> I responded on Github.H ere is what I wrote:
>>> >>
>>> >> "
>>> >> I think that in cases where individual labels are used next to 
>>>checkboxes
>>> >> or radio buttons, they constitute a part of the respective 
>>>control.
>>> >> That's
>>> >> why I think it is fair to mandate an explicit association for 
>>>those cases
>>> >> to aid the many users with motor impairments that find it hard to 
>>>place a
>>> >> mouse click on the control itself.
>>> >> I would allow for exceptions only in cases where the design does 
>>>not
>>> >> allow
>>> >> for sufficient space for individual visible labels, as in the case 
>>>of
>>> >> checkboxes placed within tables. Here, the title attribute, 
>>>aria-label
>>> >> attribute of some accessibility`supported programmatic association 
>>>with
>>> >> table headers via aria-labelledby can be used.
>>> >> So like Adam, I think it fair to define a failure for cases where 
>>>the
>>> >> label is adjacent to the control but authors have failed to make 
>>>the
>>> >> connection programmatically determinable.
>>> >> "
>>> >>
>>> >> I'd add that the minimal requirement expressed in the proposed 
>>>consensus
>>> >> focuses unduly on the needs of screen reader users for whom markup 
>>>would
>>> >> work either way. From the perspective of the many visually 
>>>impaired and
>>> >> motor-impaired users, having clickable visual labels is to 
>>>something I
>>> >> would not be shy to mandate. It's very easily done natively and 
>>>has been
>>> >> good practice for many years.
>>> >>
>>> >>
>>> >> On 21 Nov 2015, at 20:34, Andrew Kirkpatrick <akirkpat@adobe.com> 
>>>wrote:
>>> >>
>>> >> > https://github.com/w3c/wcag/issues/122#issuecomment-158676010
>>> >>
>>> >> --
>>> >> Detlev Fischer
>>> >> testkreis - das Accessibility-Team von feld.wald.wiese
>>> >> c/o feld.wald.wiese
>>> >> Thedestraße 2
>>> >> 22767 Hamburg
>>> >>
>>> >> Mobil +49 (0)157 57 57 57 45
>>> >> Fax   +49 (0)40 439 10 68-5
>>> >>
>>> >> http://www.testkreis.de
>>> >> Beratung, Tests und Schulungen für barrierefreie Websites
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >
>>>
>>>
>>>--
>>>Laura L. Carlson
>>>
>>>
>>>
>>>
>>