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

OK, this time I’m actually done writing the email.

Following up on this issue.  The group discussed this on the call on Tuesday and a couple of other people have weighed in on the GitHub issue also (https://github.com/w3c/wcag/issues/122).

On the call there was agreement that WCAG does not require that the input be wrapped in the label element or that the association be made with for/id.  Both of these are of course preferred design patterns, but the issue is whether they are required (or using aria-labelledby as this was also cited in comments as another example where the programmatic association is explicit). The group on the call agreed that even though there is appeal to saying that SC 1.3.1 requires one of these, there are a couple of reasons that WCAG 2.0 does not make this required:

1) WCAG 2.0 is technology independent so isn’t talking about technology-specific attributes, just that the relationship has the ability to be programmatically determined.  Programmatically determined does not necessarily need to be explicit in nature, it is possible to have implicit determination.  In the instance of a control that is implicitly associated with a label that may even meet 1.3.1 as well as 4.1.2 through the implicit means:
<p><input type=“checkbox”> Please send me a ton of email</p>

If the browsers and AT used to make a WCAG 2.0 conformance claim support the correct identification of the accessibility name of the control then 4.1.2 is satisfied, and if that happens then clearly the relationship is programmatically determined by the tools used and one would base a claim of accessibility support on this behavior.

Do we think that this is the best code? No, of course not, and we know that the accessibility support is likely to be more limited than if a better pattern was followed, but the way that WCAG is written if the user agent support made this work for the end user then it would pass 1.3.1.

2) Requiring that the code be written in a specific way is also saying that it must fail if it isn’t written that way, and to have a failure for WCAG (To write a failure technique) requires that the code or markup would always fail.  As indicated in #1 above, this isn’t the case for all examples that don’t use explicit association.

Related to part of the original argument in the GitHub issue, 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.

Detlev, Makoto – what do you think?  Does this make sense to you?  Others?

Thanks,
AWK

Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe

akirkpat@adobe.com<mailto:akirkpat@adobe.com>
http://twitter.com/awkawk

http://blogs.adobe.com/accessibility


From: "josh@interaccess.ie<mailto:josh@interaccess.ie>"
Reply-To: "josh@interaccess.ie<mailto:josh@interaccess.ie>"
Date: Wednesday, November 25, 2015 at 10:19
To: Andrew Kirkpatrick, Detlev Fischer, David MacDonald
Cc: WCAG
Subject: 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<mailto:akirkpat@adobe.com>>
To: "Detlev Fischer" <detlev.fischer@testkreis.de<mailto:detlev.fischer@testkreis.de>>; "David MacDonald" <david100@sympatico.ca<mailto:david100@sympatico.ca>>
Cc: "WCAG" <w3c-wai-gl@w3.org<mailto: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<mailto: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<mailto: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<http://www.linkedin.com/in/davidmacdonald100>

www.Can-Adapt.com<http://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 Mon, Nov 23, 2015 at 7:43 PM, Jonathan Avila <jon.avila@ssbbartgroup.com<mailto: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<mailto:jon.avila@ssbbartgroup.com>

703-637-8957<tel:703-637-8957> (o)
Follow us: Facebook<http://www.facebook.com/#%21/ssbbartgroup> | Twitter<http://twitter.com/#%21/SSBBARTGroup> | LinkedIn<http://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog> | Newsletter<http://eepurl.com/O5DP>

From: Wayne Dick [mailto:wayneedick@gmail.com<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<mailto: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<mailto: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<tel:613.235.4902>
>
> LinkedIn <http://www.linkedin.com/in/davidmacdonald100>
>
> www.Can-Adapt.com<http://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<mailto: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<mailto: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<tel:%2B49%20%280%29157%2057%2057%2057%2045>
>> Fax   +49 (0)40 439 10 68-5<tel:%2B49%20%280%2940%20439%2010%2068-5>
>>
>> http://www.testkreis.de<http://www.testkreis.de/>
>> Beratung, Tests und Schulungen für barrierefreie Websites
>>
>>
>>
>>
>>
>>
>>
>>
>

--
Laura L. Carlson