RE: LC 587: labeling form controls

Thanks Christophe,

I think we have an action item to clarify "relationship".  Perhaps the label
bit can be included as an example in the relateionship definition - since it
is already covered by the first half of the SC - but could be clearer.  It
can also be listed as a failure if not done. 



Gregg

 -- ------------------------------ 
Gregg C Vanderheiden Ph.D. 
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 
The Player for my DSS sound file is at http://tinyurl.com/dho6b 
 

> -----Original Message-----
> From: public-wcag-teamc-request@w3.org 
> [mailto:public-wcag-teamc-request@w3.org] On Behalf Of 
> Christophe Strobbe
> Sent: Monday, June 19, 2006 10:42 AM
> To: public-wcag-teamc@w3.org
> Subject: RE: LC 587: labeling form controls
> 
> 
> 
> At 17:24 19/06/2006, Gregg Vanderheiden wrote:
> 
> >There was also a request to reinstate 4.1.3 (even if it was 
> covered by
> >1.3.1) so that all of the 'programmatic control' provisions 
> were together.
> >
> >So you might also consider adding old 4.1.3 to 4.1.2  (we 
> had it there 
> >for awhile but it made 4.1.2 long -- so we removed it.
> >
> >If you don't have the old wording...  try looking in the history of 
> >4.1.2 in the wiki.
> 
> In the Wiki for "How to Meet 4.1.2", I found: "The name, 
> role, perceivable properties, and relationships of user 
> interface components can be programmatically determined, 
> their user-settable values can be programmatically set, and 
> notification of changes is available" (in versions 
> http://trace.wisc.edu/wcag_wiki/index.php?title=How_to_Meet_Su
> ccess_Criterion_4.1.2&oldid=18210
> through
> http://trace.wisc.edu/wcag_wiki/index.php?title=How_to_Meet_Su
> ccess_Criterion_4.1.2&oldid=18514).
> 
> Merging this with the current SC 4.1.2 would give:
> "For all user interface components, the name, role, 
> perceivable properties and relationships can be 
> programmatically determined, values that can be set by the 
> user can be programmatically set, and notification of changes 
> to these items is available to user agents, including 
> assistive technologies."
> 
> However, this does still not address the reviewer's objection 
> that "relationships" is abstract.
> 
> Another way of merging is adding the old 4.1.3 to the current 
> 4.1.2, but that is now how we normally write SCs:
> "For all user interface components, the name and role can be 
> programmatically determined, values that can be set by the 
> user can be programmatically set, and notification of changes 
> to these items is available to user agents, including 
> assistive technologies. The label of each user interface 
> control [in the Web content] that accepts input from the user 
> can be programmatically determined and is explicitly 
> associated with the control."
> 
> Regards,
> 
> Christophe
> 
> > > -----Original Message-----
> > > From: public-wcag-teamc-request@w3.org 
> > > [mailto:public-wcag-teamc-request@w3.org] On Behalf Of Christophe 
> > > Strobbe
> > > Sent: Monday, June 19, 2006 10:02 AM
> > > To: public-wcag-teamc@w3.org
> > > Subject: LC 587: labeling form controls
> > >
> > >
> > > Hi,
> > >
> > > <comment>
> > > The reviewer points out that SC 4.1.3 in the January 2006 version 
> > > [1] explicitly addressed labels for form controls:
> > > "The label of each user interface control in the Web content that 
> > > accepts input from the user can be programmatically 
> determined and 
> > > is explicitly associated with the control." In the Last 
> Call Working 
> > > Draft, this SC was removed and replaced by SC 4.1.2: "For 
> all user 
> > > interface components, the name and role can be programmatically 
> > > determined, values that can be set by the user can be 
> > > programmatically set, and notification of changes to 
> these items is 
> > > available to user agents, including assistive technologies."
> > > <q>The problem is that 4.1.2 is absolutely inadequate. 
> The "Role" of 
> > > text input field is "text input"; the name could be "keyinput". 
> > > 4.1.2 is basic software accessibility - leaving to the AT the 
> > > process of figuring out what the prompt (label) is.</q> 
> Labels are 
> > > covered by SC 1.3.1 but this is abstract and requires 
> > > interpretation. So <q>there is no SC that specifically addresses 
> > > labeling forms and I think that is a very serious mistake.</q>
> > >
> > > Proposed Change: Please reinstate 4.1.3.
> > > </comment>
> > >
> > >
> > > <discussion>
> > > SC 4.1.3 was removed on the condition that the new SC 4.1.2 got 
> > > accepted and that SC 1.3.1 would be changed to say that 
> "Information 
> > > and relationships conveyed through presentation can be 
> > > programmatically determined (...)". SC 1.3.1 also has techniques 
> > > such as "Using label elements to associate text labels with form 
> > > controls" and "Providing a label for groups of radio buttons or 
> > > checkboxes using the fieldset and legend elements."
> > > However, SC 1.3.1 does not have a "failure due to omitting labels 
> > > for form controls that are not of type hidden, submit, 
> reset, image 
> > > or button" (or "failure due to omitting labels for form 
> controls for 
> > > item selection or text input"). Should we add this?
> > > </discussion>
> > >
> > >
> > > <older_issues>
> > > I did not find Bugzilla issues that are directly related to this.
> > > I think the proposal to rework the 4.1 SCs did not result from a 
> > > Bugzilla issue. It was proposed at 
> > > 
> http://lists.w3.org/Archives/Public/w3c-wai-gl/2006JanMar/0484.html,
> > > surveyed at
> > > http://www.w3.org/2002/09/wbs/35422/2006-03-11-MISC/results#x3
> > > and resolved at
> > > http://www.w3.org/WAI/GL/2006/03/16-wai-wcag-minutes.html#item07.
> > > </older_issues>
> > >
> > >
> > > <proposed_response>
> > > [PARTIAL ACCEPT]
> > > SC 1.3.1 covers form labels. We have added a "failure due to 
> > > omitting labels for form controls for item selection or 
> text input" 
> > > to the techniques document.
> > > </proposed_response>
> > >
> > > Does this make sense? Or should we pass this on HOLD?
> > >
> > > [1] This refers to an internal draft:
> > > http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20060117/guidelines.
> > > html#ensure-compat
> > >
> > > Regards,
> > > Christophe
> > >
> > >
> > > --
> > > Christophe Strobbe
> > > K.U.Leuven - Departement of Electrical Engineering - 
> Research Group 
> > > on Document Architectures Kasteelpark Arenberg 10 -
> > > 3001 Leuven-Heverlee - BELGIUM
> > > tel: +32 16 32 85 51
> > > http://www.docarch.be/
> > >
> > >
> > > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
> > >
> > >
> > >
> 
> --
> Christophe Strobbe
> K.U.Leuven - Departement of Electrical Engineering - Research 
> Group on Document Architectures Kasteelpark Arenberg 10 - 
> 3001 Leuven-Heverlee - BELGIUM
> tel: +32 16 32 85 51
> http://www.docarch.be/ 
> 
> 
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
> 
> 
>

Received on Monday, 19 June 2006 15:55:18 UTC