RE: CfC: Checkbox and Radio button labels and 1.3.1

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; 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