RE: H65 updates

We may be experiencing unintended consequences from an change made to the understanding document in September 2013 (http://lists.w3.org/Archives/Public/public-comments-wcag20/2013Sep/0014.html).  

The goal for any input field is that users know how to complete the field correctly.  

In most cases this is simple.  A form control for "first name" has an HTML label element with a programmatically associated value that provides the name for the control.  The label element text "first name" provides the label to meet 3.3.2, and the same element is used to satisfy 4.1.2 in providing an accessible name for the control for assistive technology users.

In other cases, such as the 3-field phone number control or the text field with "search" button for a site search, it is more complicated.  

If a site has the phone number fields and they place the fields into a fieldset with the legend "Phone number".  Whether there is 1 phone number input or multiple, it seems reasonable to allow that the proximal location of the legend allows that text to serve as the label for the controls.  However, it may not be sufficient to provide support for 4.1.2, so in this case the title attribute (or aria-label) might be used, and in this way both AT and non-AT users are provided sufficient information about the control. 

Technique G131 clarifies the test that would be used to evaluate this for 3.3.2 (http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140916/G131):
"For each interface component in the content:
1. Identify the purpose of the interface component.
2. Check that any required label is present.
3. Check that each label makes the component's purpose clear."

It is worth noting that there is no check for programmatic association.

In the example of the search field, we have a technique that speaks to this directly, G167 (http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140916/G167).  

The description for G167 says:
"When a button invokes a function on an input field, has a clear text label, and is rendered adjacent to the input field, the button also acts as a label for the input field. This label helps users understand the purpose of the field without introducing repetitive text on the Web page. Buttons that label single text fields typically follow the input field.
Note: The field must also have a programmatically determined name, per Success Criterion 4.1.2."

I do agree that we need to do something to H65, as I agree that the addition of the title element doesn't help address 3.3.2.

Thoughts?
AWK

-----Original Message-----
From: Sailesh Panchang [mailto:spanchang02@yahoo.com] 
Sent: Friday, June 12, 2015 8:23 AM
To: w3c-wai-gl@w3.org; Christophe Strobbe
Subject: Re: H65 updates

Indeed it is an abuse.
Title is okay for forms with a single search box or phone# type (multipart) fields. 
In such cases, one sort of turns a blind eye towards SC 3.3.2.
It is ok for SC 4.1.2 for assigning a name to a field but not as a replacement for a label in a form with several  fields.
H65 should not be deleted but it needs to clarify usage.
Also the specs clearly say placeholder is not a substitutefor a label.
Thanks,
Sailesh


--------------------------------------------
On Fri, 6/12/15, Christophe Strobbe <strobbe@hdm-stuttgart.de> wrote:

 Subject: Re: H65 updates
 To: w3c-wai-gl@w3.org
 Date: Friday, June 12, 2015, 6:40 AM
 
 Hi,
 
 Detlev is right. H65 was specifically created for cases  where " the  visual design cannot accommodate the label" (as the  description says).
 If H65 is deleted, HTML forms can only meet SC 3.3.2 using  visible  labels. We should think about other ways to prevent abuse of
 H65 before
 removing it.
 
 Best regards,
 
 Christophe
 
 On 12/06/2015 9:36, Detlev Fischer wrote:
 > I don"t quite see the point in removing the reference  to 3.3.2 (labels or instructions) in H65 because that is  exactly the Success Criterion that the technique relates to.
 The critical bit is the qualification in H65  "when the  label element cannot be used". On longer forms (as pointed  out by Paul) it is perfectly possible to use visible labels,  so H65 does not qualify. Still, there are contexts where H65  will meet SC 3.3.2 so the reference should stay in place.
 >
 > Detlev
 >
 > On 12 Jun 2015, at 06:03, james.nurthen@oracle.com
 wrote:
 >
 >> I agree. h65 is valid but doesn't let you meet
 3.3.2 by itself.
 >>
 >> On Jun 11, 2015, at 8:04 PM, Jonathan Avila <jon.avila@ssbbartgroup.com>
 wrote:
 >>
 >>> We need to consider removing the reference to  SC 3.3.2 from H65.
 >>>
 >>> See this article
 >>> http://pauljadam.com/demos/wcagh65invalid.html

 >>>
 >>> H65
 >>> http://www.w3.org/TR/WCAG20-TECHS/H65.html

 >>>
 >>> Jonathan
 >>>
 >>> --
 >>> Jonathan Avila
 >>> Chief Accessibility Officer
 >>> SSB BART Group
 >>> jon.avila@ssbbartgroup.com
 >>>  
 
 
 --
 Christophe Strobbe
 Akademischer Mitarbeiter
 Responsive Media Experience Research Group (REMEX)  Hochschule der Medien  Nobelstraße 10
 70569 Stuttgart
 Tel. +49 711 8923 2749
 
 “It is possible to make a living making free software for  freedom  instead of closed-source proprietary malware for cops.” 
 Jacob Appelbaum,
 <http://dissenter.firedoglake.com/2012/12/28/jacob-appelbaum-on-resisting-the-surveillance-state/>

Received on Friday, 12 June 2015 15:42:06 UTC