RE: CfC: Checkbox and Radio button labels and 1.3.1

Steve Faulkner [mailto:faulkner.steve@gmail.com] wrote:

> 

> > <p><input type=“checkbox”> Please send me a ton of email</p>

> 

> The code example passes 1.3.1 Info and Relationships because the content
> is grouped by the <p> element 

 

Agreed. Specifically the <p> elements opening and closing tags serves to make <input> a child of that element, and subsequently something that can be programmatically determined (this same principle BTW, applies to CSS). WCAG 2.0 states:



programmatically determined (programmatically determinable)

 

    determined by software from author-supplied data provided in a way that different user agents, including assistive technologies, can extract and present this information to users in different modalities  

 

 

> and passes 3.3.2 Labels or Instructions as the
> control has a visible prompt, 

 

Agreed

 

 

> but fails 1.1.1 Non-text Content and 4.1.2 Name,
> Role, Value as the control does not have a name.

 

Agreed. And specifically, SC 4.1.2 states:


4.1.2 Name, Role, Value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined;…

 

Furthermore, WCAG explicitly states:

 

name

    text by which software can identify a component within Web content to the user

 

    >>> Note 1: The name may be hidden and only exposed by assistive technology,<<< whereas a label is presented to all users. In many (but not all) cases, the label and the name are the same.

 

    Note 2: This is unrelated to the name attribute in HTML.

 

It also states the following:

 

“… In HTML, information that is programmatically determinable from a link in English includes text that is in the same paragraph, list, or table cell as the link or in a table header cell that is associated with the table cell that contains the link.”

 

While that is specific to link text, the principle remains the same: you can programmatically determine information about a child element from its parent, whether that child element is the <a> (anchor) element or an <input> element.

 

 

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

> 

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

 

AND: 

<p><input type=“checkbox” title="Please send me a ton of email"> Please send me a ton of email</p>

 

 

> 

> or via aria-labelledby

> 

> <p id="label"><input type=“checkbox” aria-labelledby="label"> Please send me a ton of email</p> 

> 

> Is the above a reasonable assessment?

 

100% in agreement. The *usability* of the code: <p><input type=“checkbox”> Please send me a ton of email</p> is, without argument, far from good, but it still meets the minimum requirement(s) as authored and finalized (by consensus) in WCAG 2.0. 

 

**************

 

Meanwhile, Detlev Fischer [mailto:detlev.fischer@testkreis.de] wrote:

>
> we should also consider retiring F91 which I fought for and wrote some time ago:

> http://www.w3.org/TR/2015/NOTE-WCAG20-TECHS-20150226/F91

> 

> Why requiring table headers when the relationship can possibly be determined implicitly
> (table data  and header cells are included in the table element and the same column?)

 

Table cells (data or header) can be “grouped” though explicit association by row (the <tr> is a parent to all of the children), or implied vertically by column as the (grand)parent <table> explicitly allows for that (and makes the column determination based upon source order in each <tr>). HOWEVER, grouping cells horizontally or vertically does not indicate which cell in any given column or row is the header for that row or column, and so your Failure Technique regarding table headers at http://www.w3.org/TR/2015/NOTE-WCAG20-TECHS-20150226/F91 remains correct.

 

**************

 

Meanwhile, Paul Adam [mailto:paul.adam@deque.com] wrote:

> 

> I really hope we’re not promoting that these methods can pass WCAG!

 

There is a difference between “promoting” these methods as Best Practice, and accepting the fact that they do meet the minimum requirements of WCAG 2.0. WCAG is a W3C Recommendation that admits to being imperfect, and is not (nor ever was) intended to be a bully-stick to be used to make authors write code in only one specific way.

 

> 

> Form control associations are required in my book…

 

According to WCAG 2.0, and specifically the quotes highlighted above, those associations exist. While that may not meet your personal definition of “association”, WCAG 2.0 helpfully provided definitions of exactly what the authors meant when WCAG 2.0 was being written, and according to those definitions, it is not a failure. 

 

Finally, it is important to remember that it’s NOT “…your book…”, it’s the W3C WCAG 2.0 Recommendation. As a developer, if you choose to hold yourself to a higher standard – great. As an educator/advocate, if you want to teach that the minimum requirements of WCAG 2.0 in this instance do not provide optimum usability – that too is great. To say that a particular piece of compliant code according to the WCAG 2.0 Recommendation (<p><input type=“checkbox”> Please send me a ton of email</p>) “fails” is false. 

 

To Detlev, Paul and others who would like to see SC 1.3.1 reinterpreted… please, we’ve chased our tails around on this one now for a number of days. The overwhelming consensus I’m hearing is that we do have some additional requirements that may need to be addressed for low vision or mobility impaired users, but as Josh and Andrew have suggested, that is likely new work, and not about attempting a revisionist history of WCAG 2.0.

 

Respectfully,

 

JF

​-- 

John Foliot

Principal Accessibility Strategist

Deque Systems Inc.

 <mailto:john.foliot@deque.com> john.foliot@deque.com

 

Advancing the mission of digital accessibility and inclusion