W3C

List of comments on “Understanding WCAG 2.0” (dated 3 January 2012)

Quick access to

There are 5 open comments (sorted by their types, and the section they are about).

question comments

Comment LC-2783: The text for the SC's intent is not worded right; the benefits are incomplete /mis-represented
Commenter: Sailesh Panchang (archived message)
Context: Labels or Instructions: Understanding Success Criterion 3.3.2
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 Change:
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.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

substantive comments

Comment LC-2781: The text for the SC's intent is not worded right; the benefits are incomplete /mis-represented
Commenter: Sailesh Panchang <spanchang02@yahoo.com> on behalf of Deque Systems
Context: Labels or Instructions: Understanding Success Criterion 3.3.2
Comment (Including rationale for any proposed change):
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 Change:
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.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2782: The text for the SC's intent is not worded right; the benefits are incomplete /mis-represented
Commenter: Sailesh Panchang <spanchang02@yahoo.com> on behalf of Deque Systems
Context: Labels or Instructions: Understanding Success Criterion 3.3.2
Comment (Including rationale for any proposed change):
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 Change:
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.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

editorial comments

Comment LC-2828: Understanding Levels of Conformance unclear
Commenter: shawn@w3.org (archived message)
Context: Understanding Conformance
Name: Shawn Henry
Email: shawn@w3.org
Affiliation: W3C WAI / MIT
Document: UW
Item Number: Understanding Conformance
Part of Item: Intent
Comment Type: editorial
Summary of Issue: Understanding Levels of Conformance unclear
Comment (Including rationale for any proposed change):
Several places (such as the How to Meet / quick ref) link the word "level(s)" to http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance#uc-levels-head

This section is missing the basic description of what the levels are and how people might use them.

(Also, there are three paragraphs before you even get to mention of the three levels; the first use of the word level is unrelated "a high level of confidence"; and A, AA, and AAA" is no where in the section.)

Proposed Change:
Edit that explanation of levels to be more clear and address readers who come at it from different places and perspectives, particularly those looking for a basic idea of what the levels are in general. (I understand you don't have a definition of each level like in WCAG 1.) (I think Judy Brewer worked on explanations of the levels a few years ago and might have some input.)

A quick & easy thing that would help a bit is to include "levels A, AA, and AAA" at the top of the section so people at least have some grounding.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2829: Understanding Levels of Conformance unclear
Commenter: <noreply@w3.org> (archived message)
Context: Understanding Conformance
Name: Shawn Henry
Email: shawn@w3.org
Affiliation: W3C WAI / MIT
Document: UW
Item Number: Understanding Conformance
Part of Item: Intent
Comment Type: editorial
Summary of Issue: Understanding Levels of Conformance unclear
Comment (Including rationale for any proposed change):
Several places (such as the How to Meet / quick ref) link the word "level(s)" to http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance#uc-levels-head

This section is missing the basic description of what the levels are and how people might use them.

(Also, there are three paragraphs before you even get to mention of the three levels; the first use of the word level is unrelated "a high level of confidence"; and A, AA, and AAA" is no where in the section.)

Proposed Change:
Edit that explanation of levels to be more clear and address readers who come at it from different places and perspectives, particularly those looking for a basic idea of what the levels are in general. (I understand you don't have a definition of each level like in WCAG 1.) (I think Judy Brewer worked on explanations of the levels a few years ago and might have some input.)

A quick & easy thing that would help a bit is to include "levels A, AA, and AAA" at the top of the section so people at least have some grounding.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Add a comment.


Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: Overview.php,v 1.46 2013-10-04 08:11:33 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org