Your comments on WCAG 2.0 Public Working Draft of May, 2007 (1 of 2)

Dear Al Gilman,

Thank you for your comments on the 17 May 2007 Public Working Draft of
the Web Content Accessibility Guidelines 2.0 (WCAG 2.0
http://www.w3.org/TR/2007/WD-WCAG20-20070517/). The WCAG Working Group
has reviewed all comments received on the May draft, and will be
publishing an updated Public Working Draft shortly. Before we do that,
we would like to know whether we have understood your comments
correctly, and also whether you are satisfied with our resolutions.

Please review our resolutions for the following comments, and reply to
us by 19 November 2007 at public-comments-wcag20@w3.org to say whether
you are satisfied. Note that this list is publicly archived. Note also
that we are not asking for new issues, nor for an updated review of
the entire document at this time.

Please see below for the text of comments that you submitted and our
resolutions to your comments. Each comment includes a link to the
archived copy of your original comment on
http://lists.w3.org/Archives/Public/public-comments-wcag20/, and may
also include links to the relevant changes in the WCAG 2.0 Editor's
Draft of May-October 2007 at
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20071102/

Thank you for your time reviewing and sending comments. Though we
cannot always do exactly what each commenter requests, all of the
comments are valuable to the development of WCAG 2.0.

Regards,

Loretta Guarino Reid, WCAG WG Co-Chair
Gregg Vanderheiden, WCAG WG Co-Chair
Michael Cooper, WCAG WG Staff Contact

On behalf of the WCAG Working Group

----------------------------------------------------------
Comment 1: Suggestion for improved wording of SC 3.3.1
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0135.html
(Issue ID: 2012)
----------------------------
Original Comment:
----------------------------

suggestion:

s/identified and described/identified and what is wrong is described/

Discussion: The grammar of the sentence without the edit says that
the *item* that is in error is described to the user. What you want
is that *the error* is described to the user. Be even plainer; say
"what is wrong is described to the user."

The present sentence is a mislocution: it doesn't say what you
meant to say.

"and the error is described to the user..." is good

"and the nature of the error is described to the user..." is better

"and what is wrong is described to the user..." is yet better.

IMHO.

Al

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

We agree with your suggestion. We have revised this criterion to read,
"3.3.1 Error Identification: If an input error is detected, the item
that is in error is identified and the error is  described to the user
in text. (Level A)"

----------------------------------------------------------
Comment 2: SC 1.3.3 only identifies visual dependencies
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0139.html
(Issue ID: 2015)
----------------------------
Original Comment:
----------------------------

You have successfully dealt with my old comment.

However SC 1.3.3 still needs help

<quote
cite="http://www.w3.org/TR/2007/WD-WCAG20-20070517/Overview.html#content-structure-separation-understanding">

1.3.3 Size, Shape, Location: Instructions provided for understanding
and operating content do not rely on shape, size, visual location, or
orientation of components. (Level A)

</quote>

Problem:

This just tells you some visual characteristics that your
instructions should not be
dependent on.

It leaves open situations that are just as bad that depend on the sound of the
element.  Or its motion.  Or its smell.

Make the injunction positive:

"Instructions shall include the text identification of components that they
tell users how to use."

Provide a definition of "text identification" in the glossary.

This is in line with the clarification of 1.1.1. and 2.4.6 that needs
to be done.

Al

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

We agree that audio is an important sensory modality that needs to be
captured, and others need not be left out. We have adjusted the
provision as follows:

1.3.3 Sensory Characteristics: Instructions provided for understanding
and operating content do not rely solely on sensory characteristics of
components such as shape, size, visual location, orientation or sound.
(Level A)




----------------------------------------------------------
Comment 3: SC 3.3.2 is not testable
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0136.html
(Issue ID: 2013)
----------------------------
Original Comment:
----------------------------

At 4:27 PM -0700 17 05 2007, Loretta Guarino Reid wrote:
>----------------------------------------------------------
>Comment 26:
>
>Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
>(Issue ID: LC-1195)

OLD WCAG2 ref:

New WCAG2 ref:

http://www.w3.org/TR/2007/WD-WCAG20-20070517/Overview.html#minimize-error-suggestions

>Clause is trivially vague.  It will either be satisfied or be
>inapplicable, because there is no objective standard for when the
>"and..." condition is met.
>
>This provision is general good usability practice.
>
>The suggestions usually come from the browser's memory of user's
>response to similar questions in other content.  Hence is not a
>content requirement, but a user experience desideratum which may be
>satisfied by user's automation or the data received from the author's
>automation.
>
>Proposed Change:
>
>move to informative annex noting good usability practices that are
>especially appreciated in the PWD Web experience.
>
>----------------------------
>Response from Working Group:
>----------------------------
>
>We do not agree that the clause is trivially vague. We agree that this
>provision is good general usability practice, however, we feel that
>this is an accessibility issue because of its disproportionate impact
>on users who have cognitive disabilities that impair problem solving.
>
>----------------------------------------------------------

Reply from commentor:

OK, 'trivially vague' is too technical language.

Putting this suggestion in the document is non-trivial.  It is a good
idea.

But the success criterion as stated is not testable.  It is "unenforceably
vague."

This is because there is not way to determine without the user's error
whether the application knows an appropriate suggestion to make
as correction.

Nobody can ever fail this criterion, because it is un-testable to show
that they should have known what to suggest.

I admit that I don't know what to do on this point.  The SC fails your
self-imposed requirement of testability.  Rating this at AA is dubious
in the sense that in can never fail.

But in the spirit of the "common sense suggestions" for MMI applications,
it is a common-sense suggestion worth mentioning that may be of
particular value if you happen to be a PWD.

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

In order for the content provider to detect an error and determine a
suggestion, there should be some algorithm involved. The most obvious
way to determine if such an algorithm is deployed is to check the
business logic within the Web application server where such algorithms
most likely exist. If there is a way to look for an error, but an
algorithm to look for suggestions is lacking, then this success
criterion cannot apply.

In the case of black box testing, where the tester cannot access the
business logic, then the tester may need to make multiple attempts to
create error conditions to determine whether the algorithm exists. It
is true that if the Web content provider deploys an algorithm to look
for suggestions and opts not to provide it to the user, it would be
relatively difficult to discover its existence. The success criterion
makes room for such decisions for security purposes. However, it would
be a waste of computing resource for a Web content provider to hide
the suggestion from the user for a non-security reason. We do not find
such a scenario likely to take place.

----------------------------------------------------------
Comment 4: Checking data at each step should not be sufficient for SC 3.3.3
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0137.html
(Issue ID: 2014)
----------------------------
Original Comment:
----------------------------

At 4:27 PM -0700 17 05 2007, Loretta Guarino Reid wrote:
>----------------------------------------------------------
>Comment 27:
>
>Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
>(Issue ID: LC-1196)
>
>Sub-case 1 is by definition not applicable.  If the action is
>reversable, then the user action does not cause i.e. commit to the
>transaction.
>
>Sub-case 2 is insufficient.  Having the system check for a subset of
>the system's concerns is in no way an indication of the user's
>informed consent to commit the transaction.
>
>Sub-case 3 is the requirement.
>
>Proposed Change:
>
>Eliminate OR and leave the "opportunity to review" provision only.
>
>Make a note that if the transaction is reversible then the review is
>required before the subsequent commit transaction, but that this test
>is not required at the interim step.
>
>----------------------------
>Response from Working Group:
>----------------------------
>
>To address your concern with the first bullet we have updated it to
>require that transactions are reversible rather than actions. The
>working group believes that the second bullet is important for
>complicated transactions where it might not be appropriate to review
>all data in the final step and thus has retained that option. We have
>updated the wording of the second bullet.  The third bullet has been
>rewritten to make it clear that the user has the opportunity to review
>the results being submitted before confirming the transaction.
>
>We have revised the list in this section as follows:
>
>   1. Transactions are reversible.
>   2. Submitted data is checked for input errors before going on to
>the next step in the process.
>   3. A mechanism is available for reviewing, confirming, and
>correcting information before finalizing the transaction.

Reference in new draft:
http://www.w3.org/TR/2007/WD-WCAG20-20070517/Overview.html#minimize-error-reversible


Reply from commentor:

This is better.  You have removed my objection to point 1.

But 2. is no substitute for 1. or 3. Even if the system does 2. it
needs to afford 3. at the last step or 1. afterwards. The error
checking by the system does not confirm that the data reflects the
user's intent. Consider all the wrong-word errors that slip through
spell checking.

Al

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

We have changed bullet 2 to clarify that the user is provided an
opportunity to correct any errors that are identified:
"Data entered by the user is checked for input errors and the user is
provided an opportunity to correct them."

While bullet 3 will potentially let the user catch more errors, it
does not provide the user any assistance in finding errors. Since the
user will often be presented with data that contains no errors, we are
concerned that it may encourage users to ignore the confirmation step.
So it is not required in addition to bullet 2.

----------------------------------------------------------
Comment 5: information conveyed by color differences
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0140.html
(Issue ID: 2016)
----------------------------
Original Comment:
----------------------------

>The group thinks that situations where the density of the color would
>affect the information in such a way that it is too subtle or
>complicated to be visually rendered in another way, are extremely
>rare.

You are not thinking of all situations where information is conveyed
by color differences.

"Extremely rare" is false, and we just go through telling HTML WG
that they can't kill the 'headers' attribute because they think that
the cases where 'scope' is not enough are 'rare.'

What is sauce for the goose is sauce for the gander.

I believe that what you mean is not any "information conveyed
by color differences" as in all pseudocolor visualizations, but
rather "color-coded information" which could be explained in
the glossary as

color-coded information:

Information taking values in a small discrete set that is visually
cued by conventional colors in different areas on the canvas.

>UAAG 2.3 applies to conditional content, and is not equivalent to
>necessary information that a color blind person can't access.
>The DAISY player example of minimizing notes is a different issue
>because they are not equivalents to content. They are enhanced
>information, so it makes sense that people should take extra steps to
>access that information. The group does not think color blind people
>should be required to go elsewhere to get basic information in
>circumstances such as those covered in this success criteria. Color,
>as it applies to this success criteria, is often text based
>information, and therefore would not be covered under SC 1.1.1.

Yes, there are frequent uses of color to convey simple discrete
enumerated types of data that can be readily shown by small sets
of values of some other visual property.

But you need to state the applicability of this rule better. Limit
the 'then' clause to a 'where' that isolates the appropriate subset
of color-borne information. Your language at present still casts too
broad a net.

Al

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

New language changed to "color coding" as follows:

Color is not used as the only visual means of conveying information,
indicating an action, prompting a response, or distinguishing a visual
element.

----------------------------------------------------------
Comment 6: SC 3.3.1 at level A will result in lots of unnecessary
error explanations
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0144.html
(Issue ID: 2017)
----------------------------
Original Comment:
----------------------------

>At 4:27 PM -0700 17 05 2007, Loretta Guarino Reid wrote:
>----------------------------------------------------------
>Comment 18:
>
>Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
>(Issue ID: LC-979)

Ref:
http://www.w3.org/TR/2007/WD-WCAG20-20070517/Overview.html#minimize-error-identified

>
>Identifying the bad entry is enough so long as the entry is
>prompted/labeled adequately.  In other words affordance of help
>recovering from data entry errors is good advice, but too demanding at
>a Level A success criterion standard.
>
>Also, authors just get this wrong too easily.  How many times does the
>text explanation say "bad password" when the error was in the
>username?
>
>Error explantions should follow the culture of the desktop.  If there
>is a screen reader in use, this is the screen reader's habits for
>expressing error messages.  The content should define the error as
>formally as they can.  Let the UA and AT worry the friendly message.
>
>If the UA knows it is a type error and the type is identified, then
>that is enough to synthesize an error explanation in diction the user
>will understand in the culture of their desktop formed by their AT.
>
>System codes would not make that error.  The point is that the server
>refused the authentication information pair of username *and*
>password.
>
>Proposed Change:
>
>Separate identification of the bad data from explanation of how it is
>bad. Move explanation of nature of error to lower level. Allow
>satisfaction by either text message or metadata understandable by
>user's automation.
>
>----------------------------
>Response from Working Group:
>----------------------------
>
>As per your suggestions, in the Understanding document we have added
>that the error should be specific as possible.
>
>The working group does not think we should move the explanation of the
>nature of the error to a lower level. As a small matter of
>distinction, the success criterion does not require an explanation. It
>requires that the error is described to the user, that she be able to
>understand it. An explanation is a detailed description. The success
>criterion is not requiring a detailed description, but simply a
>description of the error, which is not as rigorous as an explanation
>of the error.

OK, we use the word differently.

>The intent section says:
>"The intent of this success criterion is to ensure that users are
>aware that an error has occurred and can determine what is wrong."
>
>The working group believes it is reasonable to require a description
>of the error at Level A, such as "error: use only numbers" for a
>telephone field that was filled with letters, rather than "an error
>has occurred" which could be confusing. A description will be
>necessary at Level A for many people with disabilities, including
>those with cognitive disabilities.

I think this will result in a lot of garbage "error explanations"
bloating the web pages if taken seriously.  And ranking it at
level A is likely to precipitate that, like the rash of alt-="ALT"
that we saw early on.

If the nature of the error is obvious from the existing label or hint
and the bad value,  a separate description of the error is
not required to acheive the 'intent.'  And it's not always
possible to say more than 'illegal value.'  That's already covered
in the identification of the bad field.  But it's required by this
SC to meet level A.

Seems like overkill to me.

>This success criterion does not prevent the use of programmatic
>information which can be used by assistive technology or the user
>agent to identify and provide error information. There must be some
>mechanism to provide the error information to the user with all
>technologies in use today and the requirement for text guarantees
>that.  Even when provided by the assistive technology or user agent
>rather than the content author, the information can still be conveyed
>in some form of text to meet this requirement.  Thus, we don't see the
>requirement for text as being too restrictive.
>
>----------------------------------------------------------

OK, leave 'in text.'

But Level A feels like a stretch.

Al

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

The working group feels that this success criterion is appropriate for
Level A. If the label on a field is sufficient to describe the error,
then identifying the error by the field label would be sufficient. It
is not necessary to be verbose to satisfy this requirement.

----------------------------------------------------------
Comment 7: Wording of Principles
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0145.html
(Issue ID: 2018)
----------------------------
Original Comment:
----------------------------

>Comment 31:
>
>Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
>(Issue ID: LC-1200)
>
>"content is perceivable" is an oxymoron.  The two are not comparable.
>The rendering is perceivable.  In the rendering, the content must be
>recognizable.
>
>----------------------------
>Response from Working Group:
>----------------------------
>
>Principles are not a technical provisions, but something to provide a
>gestalt. We have changed them to a certain extent but we want them to
>be short slogans that are easily remembered and understood as
>overarching principles.
>
>They now read:
>
>1. Perceivable - Information and user interface must be perceivable
>by the user.

change to:

Information and operable objects must be presented to the use so as
to be perceivable.

why:

User interface doesn't have to be peceiveable.  The user normally operates
on a mix of recall and recognition.  Actions that aren't needed often or are
usually remembered don't need to be presented for recognition as objects.
Actions of the UI must be discoverable, but not all perceivable until sought.

>2. Operable - User interface components must be operable by the user.

s/components/actions

Couching this in terms of 'components' leaves out Navigation, which must
be operable (by keyboard and device independently).

>
>3. Understandable - Information and operation of user interface must
>be understandable by the user.

change to:

Information and the operation ...

[otherwise it sounds as though this is just UI information, not all content
information]

>
>4. Robust - Content must be robust enough that it can be interpreted
>reliably by a wide variety of user agents, including assistive
>technologies.
>
>----------------------------------------------------------
>Comment 34:
>
>Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
>(Issue ID: LC-1203)

(as per above)

>----------------------------------------------------------
>Comment 35:
>
>Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
>(Issue ID: LC-1204)

(as per the above)

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

{partial-other}

We have edited it along these lines.  This text is now found in the
"Understanding WCAG 2.0 document".

Received on Sunday, 4 November 2007 04:01:52 UTC