RE: CfC: Checkbox and Radio button labels and 1.3.1

Makoto UEKI - Infoaxia, Inc. [mailto:makoto.ueki@gmail.com] wrote:

> 

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

> 

> Have the working group reached the consensus that using aria-label or title

> attribute passes SC 1.3.1?

 

I believe the answer is yes - both of those examples would meet the Success Criteria today.

 

 

> As I commented on the github, the visible label text itself is not

> programmatically determined even if those attributes provide the accessible

> name.

> 

> SC 1.3.1 reads "Information, structure, and relationships conveyed through

> presentation". In this case, the requirement of the SC would be to make the

> visible label text programmatically determinable as the label for the checkbox.

 

Actually, no, not exactly. From "Understanding SC 1.3.1" (http://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html): 

 

KEY TERMS:

 

               Presentation:     rendering of the content in a form to be perceived by users 

 

               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

                  * Example 1: Determined in a markup language from elements and attributes that are accessed directly by commonly available assistive technology.

                  * Example 2: Determined from technology-specific data structures in a non-markup language and exposed to assistive technology via an accessibility API that is supported by commonly available assistive technology. 

 

               Relationships:     meaningful associations between distinct pieces of content 

 

               Structure:

                    *  The way the parts of a Web page are organized in relation to each other; and

                    *  The way a collection of Web pages is organized

 

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

 

Taking the requirements individually:

 

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

 

Information: 

               * There is a form input of TYPE: checkbox. Visually rendered as a box on screen, and announced to the screen reader via the AAPI.

               * The checkbox, when selected, allows the user to submit the following: "Please send me a ton of email". 
                              * The non-sighted screen-reader user knows this because of the Accessible Name applied to the form input. 

                              * The sighted user knows this because the checkbox and onscreen "label" suggest this due to visual proximity.

 

Structure:

* The input is contained inside of the paragraph element, thus the text and the input are related - programmatically associated - as children of the paragraph. While this is hardly a Best Practices example, screen readers *can* determine individual paragraphs, and so the requirement is met. 

 

Not mentioned, but perhaps relevant here, is that due to the fact that the screen reader goes into "Forms Mode" [sic] querying the paragraph and page structure becomes significantly more difficult, as the end user needs to switch between the physical and virtual cursor. This is a *usability* problem however (and a significant one), but not an actual access / accessibility problem as the end user *can* determine what is required to complete the form when an accessible name is applied to the input.  

NOTE: Somebody did mention that perhaps if the aria-label or @title string was not identical to the on-screen text (in the paragraph - or grouping element) then *THAT* would be a Failure, and I agree. It's the fact that the label text string and the visible text string are identical which gives it the information equivalent, and the fact that both the onscreen text and the form input are contained within one grouping element (<P>) that allows it to claim conformance to SC 1.3.1.

 

 

Relationship (conveyed through presentation): 

* BECAUSE the aria-label content, and the visual on-screen content is identical, the label provides the equivalent user experience - all users (sighted and non-sighted) are provided with the required information: this checkbox will submit "Please send me a ton of email". The relationship between the two ‘things’ (a form input and on-screen text) is created because they are both children of the same parent <p> element.

 

 

JF