- From: Christophe Strobbe <christophe.strobbe@esat.kuleuven.be>
- Date: Mon, 19 Jun 2006 17:42:23 +0200
- To: public-wcag-teamc@w3.org
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_Success_Criterion_4.1.2&oldid=18210 through http://trace.wisc.edu/wcag_wiki/index.php?title=How_to_Meet_Success_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:42:35 UTC