RE: CfC: Checkbox and Radio button labels and 1.3.1

Ø  I agree with Andrew here that 4.1.2 includes HTML element and controls – not just custom scripted controls, which is why I generally place requirements and failures for FRAMES under 4.1.2, as one instance of binding HTML elements (and controls), for name and role, in a programmatically determinable way, to AAPIs.

I actual do agree – but IMO the custom control bit is confusing to readers and I’ve had major plays in the US government tell me that SC 4.1.2 only applied to custom controls because of that statement in the understanding document.  So I would suggest we update it to say something like

Note: When web authors develop or script their own user interface components the name, role, and value properties may not be implicitly available without being programmatically exposed by the author.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group
jon.avila@ssbbartgroup.com
703.637.8957 (o)
Follow us: Facebook<http://www.facebook.com/#!/ssbbartgroup> | Twitter<http://twitter.com/#!/SSBBARTGroup> | LinkedIn<http://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog> | Newsletter<http://eepurl.com/O5DP>

From: Katie Haritos-Shea GMAIL [mailto:ryladog@gmail.com]
Sent: Tuesday, December 08, 2015 10:13 AM
To: 'Andrew Kirkpatrick'; Jonathan Avila
Cc: '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 agree with Andrew here that 4.1.2 includes HTML element and controls – not just custom scripted controls, which is why I generally place requirements and failures for FRAMES under 4.1.2, as one instance of binding HTML elements (and controls), for name and role, in a programmatically determinable way, to AAPIs.

​​​​​


* katie *

Katie Haritos-Shea
Senior Accessibility SME (WCAG/Section 508/ADA/AODA)

Cell: 703-371-5545 | ryladog@gmail.com<mailto:ryladog@gmail.com> | Oakton, VA | LinkedIn Profile<http://www.linkedin.com/in/katieharitosshea/> | Office: 703-371-5545

From: Andrew Kirkpatrick [mailto:akirkpat@adobe.com]
Sent: Monday, December 7, 2015 10:28 PM
To: jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>
Cc: Steve Faulkner <faulkner.steve@gmail.com<mailto:faulkner.steve@gmail.com>>; Paul Adam <paul.adam@deque.com<mailto:paul.adam@deque.com>>; josh@interaccess.ie<mailto:josh@interaccess.ie>; Detlev Fischer <detlev.fischer@testkreis.de<mailto:detlev.fischer@testkreis.de>>; David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>>; Makoto UEKI <ueki@infoaxia.com<mailto:ueki@infoaxia.com>>; WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: Re: CfC: Checkbox and Radio button labels and 1.3.1

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