W3C home > Mailing lists > Public > public-comments-wcag20@w3.org > June 2007

LC-979 respectfully disagree [was: Re: Your comments on WCAG 2.0 Last Call...]

From: Al Gilman <Alfred.S.Gilman@IEEE.org>
Date: Fri, 22 Jun 2007 21:56:49 -0400
Message-Id: <p06110416c2a228c1b8e7@[10.0.1.2]>
To: public-comments-WCAG20@w3.org

>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
Received on Saturday, 23 June 2007 01:57:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:08 UTC