RE: CfC: Checkbox and Radio button labels and 1.3.1

> <label><input type="radio" name="gender">Male</label> <label><input type="radio" name="gender">Female</label> </p> also passes 1.3.1 and does not require fieldset/legend or other grouping mechanism?

Well for the purposes of SC 1.3.1 I suppose you could pass -- but 4.1.2 would require the group label be part of the name IMO.  But this whole discussion raises questions about grouping mechanisms and accessibility support.  Just about anything can be programmatically determined -- but that doesn't mean it's accessibility supported.  For example, CSS could be used to associate pseudo content or generic containers like divs can be used instead of fieldsets and headings could be used instead of legend, etc.  This is a slippery slope and we need better guidance to help people make a determination.

Based on the input I got earlier -- if the visual label and programmatic label matched the radio buttons wouldn’t even need to be in the same container to have a "relationship".  We need some sort of decision tree like the name calculation to help people figure this out.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group 
jon.avila@ssbbartgroup.com
703.637.8957 (o) 
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter


-----Original Message-----
From: Sailesh Panchang [mailto:sailesh.panchang@deque.com] 
Sent: Tuesday, December 08, 2015 10:41 AM
To: Andrew Kirkpatrick
Cc: Jonathan Avila; Steve Faulkner; Paul Adam; josh@interaccess.ie; Detlev Fischer; David MacDonald; Makoto UEKI; WCAG
Subject: Re: CfC: Checkbox and Radio button labels and 1.3.1

I too was flummoxed by the reference to SC 1.1.1 for the checkbox control. ... I agree with you Jonathan that it does not apply.
If <p><input type="checkbox">Send me a ton of email</p> minimally passes SC 1.3.1, then I suppose all accessibility tools and evaluations  already done  may be suspect when they fail markup like the above for lack of title or label etc.
Also, markup like
<p>Select gender:
<label><input type="radio" name="gender">Male</label> <label><input type="radio" name="gender">Female</label> </p> also passes 1.3.1 and does not require fieldset/legend or other grouping mechanism?
Thanks,
Sailesh


On 12/7/15, Andrew Kirkpatrick <akirkpat@adobe.com> wrote:
> Jonathan,
> My reading of that is just that the WG felt that 4.1.2 was expected to 
> be handled by the native system for those controls. There is also this 
> note in understanding which confirms to me that 4.1.2 applies for control labeling:
>
> Note: Success Criterion 4.1.2 requires a programmatically determinable 
> name for all user interface components. Names may be visible or invisible.
> Occasionally, the name must be visible, in which case it is identified 
> as a label. Refer to the definition of name and label in the glossary 
> for more information.
>
> I too generally agree that 1.1.1 refers to 4.1.2 for controls.
>
> AWK
>
> Sent from my iPad
>
> On Dec 7, 2015, at 7:34 PM, Jonathan Avila 
> <jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>> wrote:
>
> As a general FYI - I don't consider that SC 1.1.1 applies to controls 
> because of the following passage from the understanding document:
>
> Except for the situations listed below... Controls, Input: If non-text 
> content is a control or accepts user input, then it has a name that 
> describes its purpose. (Refer to Guideline 4.1 for additional 
> requirements for controls and content that accepts user input.) 
> (Understanding SC
> 1.1.1<http://www.w3.org/TR/UNDERSTANDING-WCAG20/text-equiv-all.html>)
>
> Furthermore, I read that standard controls are not covered under SC 
> 4.1.2 as indicated by this note from understanding SC 4.1.2
>
> Note: This success criterion is primarily for Web authors who develop 
> or script their own user interface components. (Understanding SC
> 4.1.2<http://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html

> >)
>
> So, IMO this is really a SC 3.3.2 and SC 1.3.1 topic and not SC 1.1.1 
> and not SC 4.1.2 - unless the understanding documents are out of sync 
> with the groups understanding.
>
> Jonathan
>
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>
>
> 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: Andrew Kirkpatrick [mailto:akirkpat@adobe.com]
> Sent: Monday, December 07, 2015 6:35 PM
> To: Steve Faulkner; Paul Adam
> Cc: josh@interaccess.ie<mailto:josh@interaccess.ie>; Detlev Fischer; 
> David MacDonald; Makoto UEKI; WCAG
> Subject: Re: CfC: Checkbox and Radio button labels and 1.3.1
>
> <p><input type="checkbox"> Please send me a ton of email</p>
>
> Apologies, but I am getting confused here.
>
> The code example passes 1.3.1 Info and Relationships because the 
> content is grouped by the <p> element and passes 3.3.2 Labels or 
> Instructions as the control has a visible prompt, but fails 1.1.1 
> Non-text Content and 4.1.2 Name, Role, Value as the control does not have a name.
>
> This may or may not pass 1.3.1 and 4.1.2/1.1.1 as a result of the 
> implied relationship and the assistive technology support for that 
> relationship.  It is impossible to say that it passes or fails without 
> that additional information.  If I pick assistive technologies and 
> browsers that read the accessibility name correctly from that 
> undesirable markup then I would pass
> 4.1.2/1.1.1 as it has a programmatically determinable name and for the 
> same reason I'd pass 1.3.1.  If the name doesn't get read, then it not 
> only doesn't have a programmatically determinable name but since the 
> text that is used for the 3.3.2 label is right there the fact that it 
> wasn't recognized is a sign that the relationship isn't programmatically determinable either.
>
> As a developer, this is just how you don't want to do this.  You want 
> to pick a technique that provides greater rigor and predictability, 
> but for WCAG 2.0 this will not always fail.
>
> There are a number of possible methods to resolve the failure state
> including:
>
> via label
> <p><label><input type="checkbox"> Please send me a ton of 
> email</label></p>
>
> AWK: This (or with the for/id attributes) is what WCAG techniques 
> promote in the examples.  Clearly the best, most native way.
>
> via aria-label or title attribute
> <p><input type="checkbox" aria-label="Please send me a ton of email"> 
> Please send me a ton of email</p>
>
> AWK: This also works.  Some people on the list have disagreed saying 
> that this fails 1.3.1.
>
> or via aria-labelledby
>
> <p id="label"><input type="checkbox" aria-labelledby="label"> Please 
> send me a ton of email</p>
>
> AWK: yep, also good.
>
> Does that help clarify at all Steve, or just mess it up further?
>
> AWK
>

Received on Tuesday, 8 December 2015 15:55:30 UTC