Re: ( LC-2825)

 Dear spanchang02@yahoo.com,

The Web Content Accessibility Guidelines Working Group has reviewed the
comments you sent [1] on the Last Call Working Draft [2] of the
Understanding WCAG 2.0 (Public Review Draft) published on 11 Jul 2013.
Thank you for having taken the time to review the document and to send us
comments!

The Working Group's response to your comment is included below.

Please review it carefully and let us know by email at
public-comments-wcag20@w3.org if you agree with it or not before 2 Oct
2013. In case of disagreement, you are requested to provide a specific
solution for or a path to a consensus with the Working Group. If such a
consensus cannot be achieved, you will be given the opportunity to raise a
formal objection which will then be reviewed by the Director during the
transition of this document to the next stage in the W3C Recommendation
Track.

Thanks,

For the Web Content Accessibility Guidelines Working Group,
Michael Cooper
W3C Staff Contact

 1. http://www.w3.org/mid/<E1Uqaov-0002p7-0J@nelson.w3.org> 
 2. http://www.w3.org/WAI/GL/2013/WD-UNDERSTANDING-WCAG20-20130711/


=====

Your comment on :
> Summary: The text for the SC's intent is not worded right; the benefits
> are incomplete /mis-represented  
> 
> Refer to: The intent of this Success Criterion is to help users avoid
> making mistakes when their input is required. To help avoid mistakes it
> is good user interface design to provide simple instructions and cues
> for entering information. 
> Some users with disabilities may be more likely to make mistakes than
> users without disabilities or recovery from mistakes may be more
> difficult, making mistake avoidance an important strategy for users with
> disabilities. People with disabilities rely on well documented forms and
> procedures to interact with a page. Blind users need to know exactly
> what information should be entered into form fields and what the
> available choices are. 
> And one of the benefits is:
> •Providing examples of expected data formats help users with
> cognitive, language and learning disabilities to enter information
> correctly.
>  
> Comment:
> As the Web page author if I placed 2 edit boxes for last and first name
> respectively (without any labels or instructions), will a sighted
> non-disabled user know what these controls are for and not make
> mistakes?
> Simply put, the primary objective of the SC is to require labels or
> instructions that clearly convey what input data is expected in a form
> control. 
> In other words the purpose of the control should be clearly indicated.
> By the very definition  of the term label in WCAG2, 
> - the label is supposed to identify the component, the form control in
> this case.    
> - the label is supposed to be available to all users.
> The intent skirts this altogether.
> Then there are passwords that are valid without number or special
> character or upper case letter ... for different websites.
> So anyone can make mistakes if the expected data format is not 
> specified when it is out of the ordinary - nothing to do with "users
> with cognitive, language and learning disabilities".
> Likewise, if required fields are not indicated, any user's form
> submission may fail.
> Labels for form controls are not placed primarily to  prevent users from
> making mistakes but to identify the control in the first place. 
> There are other SC that deal with error identification and recovery.
> A significant benefit of explicit label association that helps  some
> users click on a label to move focus into the field or check a checkbox
> / radio button is not mentioned at all. 
> 
> Proposed wording:
> The intent of this success criterion is to have content authors place
> instructions or labels that identify the controls in a form so that
> users know what input data is expected.
> Instructions or labels may also specify data formats for fields
> especially if they are out of the customary formats or if there are
> specific rules for correct input.
> Content authors may also choose to make such instructions available to
> users only when the individual control has focus especially when
> instructions are long and verbose.
> It is customary to place labels to the left of (or above) text boxes.
> Labels for radio buttons / checkboxes  are often to the right of the
> control.
> There are specific benefits of using labels:
> i. When label elements are associated with input elements: 
> - the label is spoken by screen readers when the field receives focus.
> - users with impaired motor control are helped by a larger clickable
> area for the control, since clicking on the label or the control will
> activate the control. 
> ii. Field labels located in close proximity to the associated field
> assist users of screen magnifiers because the field and label are more
> likely to be visible within the magnified area of the page.
> iii. Specifying data formats for fields where appropriate and
> identifying required fields increases the likelihood of successful
> first-time form submission.


Working Group Resolution (LC-2825):
Thank you for your comment.  We will adjust the intent section of
Understanding 3.3.2 as follows, incorporating many of your edits:

The intent of this success criterion is to have content authors place
instructions or labels that identify the controls in a form so that users
know what input data is expected. Instructions or labels may also specify
data formats for fields especially if they are out of the customary formats
or if there are specific rules for correct input. Content authors may also
choose to make such instructions available to users only when the
individual control has focus especially when instructions are long and
verbose.

The intent of this Success Criterion is not to clutter the page with
unnecessary information but to provide important cues and instructions that
will benefit people with disabilities. Too much information or instruction
can be just as much of a hindrance as too little. The goal is to make
certain that enough information is provided for the user to accomplish the
task without undue confusion or navigation.

Note: If labels are provided, the label relationship to the object labeled
must be programmatically determined or described in text per Understanding
Success Criterion 1.3.1 Info and Relationships.

Specific Benefits of Success Criteria 3.3.2:
* When label elements are associated with input elements the label is
spoken by screen readers when the field receives focus and users with
impaired motor control are helped by a larger clickable area for the
control, since clicking on the label or the control will activate the
control. 
* Field labels located in close proximity to the associated field assist
users of screen magnifiers because the field and label are more likely to
be visible within the magnified area of the page.
* Providing examples of expected data formats help users with cognitive,
language and learning disabilities to enter information correctly.
* Clearly identifying required fields prevents a keyboard only user from
submitting an incomplete form and having to navigate the redisplayed form
to find the uncompleted field and provide the missing information.

----

Received on Sunday, 22 September 2013 14:46:56 UTC