Your comments on WCAG 2.0 Last Call Draft of April 2006 (7 of 8)

Comment 90:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1117)

Situation A - If a mandatory field contains no information: also add
"and provides an example of a correct answer"

Proposed Change:

For example, incorrectly filled out fields have a message that says
"This field has been filled out incorrectly. Please enter your age,
for example "18" "

----------------------------
Response from Working Group:
----------------------------

The Working Group does not feel that requiring examples of mandatory
fields is required in all situations.    For example, an example for a
required first or last name field is generally not necessary.
Likewise, there is no description needed for a drop down selection.
However, we have added a note that some of the situations may be
combined.

Note: In some cases, more than one of these situations may apply. For
example, when a mandatory field also requires the data to be in a
specific format.

----------------------------------------------------------
Comment 91:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1118)

Examples: The two examples should be moved to Advisory Techniques

----------------------------
Response from Working Group:
----------------------------

The working group believes that these examples are just specific
instances of some of the already listed future advisory techniques.
There are many ways of meeting this success criterion and we don't
want to give undue weight to particular instances by providing
advisory techniques about some methods and not others.

The example titled "Additional Help for Correcting An Input Error"
would be covered in the "Displaying errors and suggestions in the
context of the original form (for example, re-displaying a form where
input errors and suggestions for correction are highlighted and
displayed in the context of the original form)" technique.

The example about correcting the input of months would be covered in
the  technique titled, "Providing a text message that contains
information about the number of input errors, suggestions for
corrections for each item, and instructions on how to proceed".


----------------------------------------------------------
Comment 92:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1119)

Is this SC about providing corrections to field errors or highlighting
field errors. The techniques and examples seem contradictory

Proposed Change:

Clarify the techniques and examples

----------------------------
Response from Working Group:
----------------------------

The working group feels that the three situations in How To Meet SC
3.3.2 (formerly 2.5.2) do require that suggestions for correction be
provided. The description and examples in these techniques provide
general instructions for how to highlight the error and what type of
information should be provided to help the user correct the error.
The How To Meet document has also been updated to indicate that more
than one situation and technique may apply.  We have also retained
Situation A about mandatory fields since the user needs to be informed
that a field is required but may not always require suggested
corrections such as in the case of a field requiring the user name.

In addition, the following HTML and Client Side Scripting future
Techniques have been added as sufficient for Situations B and C

Situation B: If information for a field is required to be in a
specific data format:

1. G85: Providing a text description when user input falls outside the
required format or values
2. Providing links to suggested correction text "close to" form
fields, or providing the suggested correction text itself directly on
the Web unit "next to" form fields (future link)
3. SCR18: Providing client-side validation and alert (SCRIPT)
4. Providing client-side validation and adding error text via the DOM
(future link)

Situation C: Information provided by the user is required to be one of
a limited set of values:

1. G84: Providing a text description when the user provides
information that is not in the list of allowed values
2. Providing links to suggested correction text "close to" form
fields, or providing the suggested correction text itself directly on
the Web unit "next to" form fields (future link)
3. SCR18: Providing client-side validation and alert (SCRIPT)
4. Providing client-side validation and adding error text via the DOM
(future link)

----------------------------------------------------------
Comment 93:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1120)

Situation A - If a mandatory field contains no information: recommend
replacing text "text message" with another word - this has
connotations with mobile phones

Proposed Change:

Rewrite the technique

----------------------------
Response from Working Group:
----------------------------

The working group has updated the title of technique G83 to,
"Providing text descriptions to identify required fields that were not
completed." We have also replaced occurrences of "text message" with
"text description."

----------------------------------------------------------
Comment 94:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1121)

Situation A - If an application causes a legal transaction…: what is a
"period of time"?  Is this going to be quantified? Should we be doing
that?

Proposed Change:

Clarify the Technique

----------------------------
Response from Working Group:
----------------------------

When this technique is completed, guidelines for the period of time
will be qualified within the technique based on the situations
provided. For example, when accepting an on-line loan offer there may
be a legal requirement that the transaction can be reversed within a
certain number of hours or days.  A loan payment, however, may have a
much shorter time period to cancel.

----------------------------------------------------------
Comment 95:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1122)

Situation B - If an action causes information to be deleted… Providing
a message to the user asking him or her to confirm…: I disagree that
this should be a valid technique. There should be further ability to
recover deleted information

Proposed Change:

Remove this Technique

----------------------------
Response from Working Group:
----------------------------

The working group believes that providing a confirmation is sufficient
before deleting information and has included this option in the
success criterion text.  Not all deletions can be easily reversed. For
example, if a user has placed a hold on an event ticket, deleting that
hold may immediately make that ticket available for purchase by
another user. The action is therefore not reversible if there are then
no more tickets available for purchase.


----------------------------------------------------------
Comment 96:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1123)

Situation B - If an action causes information to be deleted… Requiring
a user to select a checkbox…: This technique doesn't make sense

Proposed Change:

Rewrite the technique

----------------------------
Response from Working Group:
----------------------------

The intent of this future technique is to force the user to confirm
that he is aware that a deletion action will occur.  We have rewritten
the title of the technique to help clarify this intent.

Requiring a user to select a confirmation checkbox before submitting
an action that causes information to be deleted. (future link)

----------------------------------------------------------
Comment 97:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1124)

Benefits: These SC do not assist people with cognitive disabilities

Proposed Change:

Remove from the Benefits section that these SC assist people with
cogntive disabilities

----------------------------
Response from Working Group:
----------------------------

We have revised the Benefits section of SC 3.1.1 and 3.1.2 to clarify
how this success criterion assists people with certain classes of
cognitive, learning, or language disabilities.

----------------------------------------------------------
Comment 98:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1125)

Resources: The Juicy Studio Readability Comprehension tool should be included

----------------------------
Response from Working Group:
----------------------------

Thanks for this recommendation. We have added this to the resources
for Success Criterion 3.1.5.

----------------------------------------------------------
Comment 99:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1126)

RUBY element: Is the RUBY element supported by any user agents?  If
not this should be deleted or lack of support should be mentioned

----------------------------
Response from Working Group:
----------------------------

Since ruby markup is only defined for XHMTL 1.1, this is a sufficient
technique if XHTML 1.1 is an accessibility-supported technology and is
relied on. We added information to the User Agent Notes about
additional support for ruby in Internet Explorer.

----------------------------------------------------------
Comment 100:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1127)

Viewport: What is the definition of this?

Proposed Change:

Replace viewport with another word or define it

----------------------------
Response from Working Group:
----------------------------

The term "viewport" was taken from the User Agent Accessibility
Guidelines. We have added the definition of viewport to the WCAG2
Glossary.

----------------------------------------------------------
Comment 101:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1128)

A change in content is not always a change in context…: I would argue
that a change in content is always a change in context. How do screen
readers or magnifiers deal with expanding menus etc?

Proposed Change:

Clarify or rewrite SC

----------------------------
Response from Working Group:
----------------------------

A change in content that occurs because the user has requested a
different view of the current content is not considered a change of
context. However, it is necessary for assistive technology to be
informed of the change. SC 4.1.2 has been changed to include state and
properties among the information that must be programmatically
determined and for which notifications of changes must be available to
assistive technology.

4.1.2 Name-Role-Value: For all user interface components, the name and
role can be programmatically determined, states, properties, and
values that can be set by the user can be programmatically determined
and programmatically set, and notification of changes to these items
is available to user agents, including assistive technologies.

----------------------------------------------------------
Comment 102:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1129)

There are examples in the Intent section

Proposed Change:

All examples should be in the Examples or Failures section

----------------------------
Response from Working Group:
----------------------------

The examples in this item are not examples of the success criterion or
meeting the success criterion but rather examples of what we mean by
one of the terms in the success criterion.  So these particular
examples can't go in the examples section.

----------------------------------------------------------
Comment 103:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1130)

Needs more examples

----------------------------
Response from Working Group:
----------------------------

This success criterion requires that you not do something.  We don't
provide examples of things not to do because they can be misunderstood
as examples of how to conform.  We tried to think of positive examples
of thing to do that didn't violate the provision but that was pretty
much anything. We have provided one.  If you can think of another
positive example (not an example of a failure) we would be happy to
include it as well.

----------------------------------------------------------
Comment 104:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1131)

Submit buttons: Research has found that labelling a button "Go" is not
informative enough. Buttons should be labelled "Find", "Submit",
"Search" etc instead

Proposed Change:

Change the technique & replace "Go" with "Find", "Search" etc

----------------------------
Response from Working Group:
----------------------------

We have changed the example in H32 to make the button label more
explicit, and we have removed "Go" from the name of the Client-side
Scripting technique.

Received on Thursday, 17 May 2007 23:48:53 UTC