- From: Sailesh Panchang <sailesh.panchang@deque.com>
- Date: Fri, 20 Nov 2015 10:42:03 -0500
- To: Andrew Kirkpatrick <akirkpat@adobe.com>
- Cc: Gregg Vanderheiden RTF <gregg@raisingthefloor.org>, "jon.avila@ssbbartgroup.com" <jon.avila@ssbbartgroup.com>, John Foliot <john.foliot@deque.com>, Paul Adam <paul.adam@deque.com>, GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
Andrew, Your example is a certain "pass" but the one below may not be so clear: If non-PD visible label is "Phone number (10 digits)" but title / aria-label is "Phone number", or non-PD visible label is "First name" and title or aria-label is "Name" Maybe a failure technique needs to be added to demonstrate such situations? Best regards, Sailesh Panchang On 11/20/15, Andrew Kirkpatrick <akirkpat@adobe.com> wrote: > So, just as an actual example, here’s one possible bit of code that one > might encounter: > > <p>What is your favorite color?</p> > <input type="radio” name=“aa” value=“a1” title="What is your favorite > color?: Red"> Red<br> > <input type="radio” name=“aa” value=“a2” title="What is your favorite > color?: Blue"> Blue<br> > … > > And yes, one would be better off doing this, but we aren’t talking about > what is better, we are talking about what is sufficient to meet the standard > we have today, whether we like the standard or don't: > <fieldset><legend>What is your favorite color?</legend> > <label><input type="radio" value="a1"> Red</label> > <label><input type="radio" value="a2"> Blue</label> > ... > </fieldset> > > What do people think, does the first, less-well coded example pass 1.3.1? > > Thanks, > AWK > > Andrew Kirkpatrick > Group Product Manager, Accessibility > Adobe > > akirkpat@adobe.com > http://twitter.com/awkawk > http://blogs.adobe.com/accessibility > > From: CAE-Vanderhe > Date: Thursday, November 19, 2015 at 20:21 > To: Jonathan Avila > Cc: John Foliot, "paul.adam@deque.com<mailto:paul.adam@deque.com>", Andrew > Kirkpatrick, WCAG > Subject: Re: GitHub issue on checkbox and radio button labels > > Sorry to be cryptic > > by “relationship between the label and the control…” I just meant that > this label went with that control. > > and yes - accessible names (if they are different than the visible names) > should have the same meaning. > > Gregg > > > > On Nov 19, 2015, at 3:30 PM, Jonathan Avila > <jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>> wrote: > >> the requirement is not that it be programmatically connected — but that >> the relationship between the label and the control be programmatically >> determinable if it can be visually determinable (for example). > > Gregg, I agree with you on the programmatically connected statement, > however, I would very much like to get more information from you on what > “relationship between the label and the control...” means. Does this mean > the programmatic name must match – what criteria can we use to be sure the > relationship is there other than the label text and the accessible name are > similar or mean the same thing, and include all relevant details such as > required state, etc. > > Thank you. > > 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: Gregg Vanderheiden [mailto:gregg@raisingthefloor.org] > Sent: Thursday, November 19, 2015 1:49 PM > To: John Foliot > Cc: Paul Adam; Jonathan Avila; Andrew Kirkpatrick; GLWAI Guidelines WG org > Subject: Re: GitHub issue on checkbox and radio button labels > > correct > the requirement is not that it be programmatically connected — but that the > relationship between the label and the control be programmatically > determinable if it can be visually determinable (for example). > > g > > > > On Nov 19, 2015, at 1:36 PM, John Foliot > <john.foliot@deque.com<mailto:john.foliot@deque.com>> wrote: > > Paul Adam wrote: >> >> 1.3.1 Info and Relationships: Information, structure, and relationships >> conveyed through presentation can be programmatically determined or are >> available in text. (Level A) >> >> Is there a definition in WCAG for the term "or are available in text.” >> >> So a title attribute can create not just an accessible name 4.1.2 but also >> a relationship connection 1.3.1? I could see the argument for >> aria-labelledby as that’s an association but aria-label or title are not >> connecting anything programmatically to the input. > > > I think WCAG’s non-normative text is fairly clear here: > > From Understanding SC 1.3.1 - Examples of Success Criterion 1.3.1 > ( > http://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html#content-structure-separation-programmatic-examples-head) > > A form where the labels for the checkboxes can be programmatically > determined: > In a form, the labels for each checkbox can be > programmatically determined by assistive technology. > [JF: AT no time does SC 1.3.1 speak to “association” nor “connection” – > simply AND EXCLUSIVELY programmatic determination] > > And then from Understanding SC 1.3.1 - Key Terms: > (http://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html#key-terms) > > 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. > > [JF: <label> is an element, aria is a collection of attributes. My read here > is that either is acceptable, as long as they are ”accessed directly by > commonly available assistive technology”. This is achieved via the > Accessibility APIs where the Accessible Name is programmatically associated > to the form input, and can then subsequently be programmatically > determined.] > > > Next, go here: > http://www.w3.org/TR/html-aam-1.0/#accessible-name-and-description-calculation > (Mapping form inputs) > HTML Accessibility API Mappings 1.0 > 5.5 Other Form Elements > Other Form Elements Accessible Name Calculation (This includes checkbox and > radio button) > > 1. Use aria-labelledby > 2. Otherwise use aria-label > 3. Otherwise use label element > 4. Otherwise use title attribute > 5. If none of the above yield a usable text string there is no accessible > name > > > [JF: Translation: The various Accessibility APIs will try to determine the > “Accessible Name” of a form input using the above 5 listed solutions, IN > THAT ORDER. Once the Accessible Name has been determined, the processing > stops. This then establishes the ‘relationship’ to the Accessibility API, > and binds it “programmatically” - and subsequently meeting the WCAG > requirement. “ > > In practice, using the title attribute is not a great idea, as many AT’s > have elected to ignore that under most circumstances – the exception being > when used in Forms. Even then, the combined specs agree that @title is the > last resort: > “…with HTML title attribute having the lowest precedence…” > > > > What Paul appears to be arguing for is better *usability*, and I think that > none of us would disagree that improved usability is a worthwhile goal. But > from my years of working with WCAG 2 I’ve never actually seen a Success > Criteria mandate a specific behavior or even user pattern – in actual fact > it seems that this was studiously avoided. This is also one of the reasons > why many of the Success Criteria have multiple Techniques. > > Based on this, I would suggest the following: > > For best Usability, use the <label> element with your checkboxes, as it will > make the associated (programmatically determinable) Accessible name also > “interactive” (in that you can click on it with a mouse… if of course you > are using a mouse). I’ll note here as well that all form inputs > automatically are in the document’s tab-order, so *another* way of placing > focus on a checkbox would be to tab to it (but again, WCAG doesn’t mandate > that behavior either). > > For determining conformance to WCAG however, any of the four options noted > above - use aria-labelledby, otherwise use aria-label, otherwise use label > element, or use title attribute - will meet the Success Criteria’s > requirement for “…labels for each checkbox can be programmatically > determined by assistive technology.” > > JF > >
Received on Friday, 20 November 2015 15:42:32 UTC