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:41:37 UTC