Edit comment LC-979 for Accessibility Guidelines Working Group

Quick access to

Previous: LC-978 Next: LC-1449

Comment LC-979: Comment Shortname:; Commenter: Al Gilman <Alfred.S.Gilman@IEEE.org>; Message-id:; Section of the document concerned:

or; Refinement of the section concerned:; Status:
assigned to; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
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 1 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.; Related issues: (space separated ids); WG Notes: [TEAMC] The SC says: "If an input error is detected, the error is identified and described to the user in text" Al is saying we are requiring an "explanation" and he is suggesting we move the requirement for that explanation to a lower level. However, we are simply requiring that the error is "described" to the user, that she be able to understand it. The "Gage Dictionary" defines an "explanation" as a "detailed description" we are not requiring a detailed description. But simply a description. I think that description should remain at level 1. 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." I think it entirely reasonable that we require a description of the error such as "error: use only numbers" for a telephone field that was filled with letters, rather than "an error has occurred". We have been getting criticism for the (understandable) lack of support for cognitive issues. THis is one place where we are helping cognitive issues. And as such I think we need to keep it. ANDI adds: Regarding 979, I think we should also address the concern, "Allow satisfaction by either text message or metadata understandable by user's automation.". This also came up in issue 629. Can we include the response from 629 in this response as well? David responds: yes, I have added the text of 629's response to this one. Although currently the SC requires satisfaction. Becky adds: The better way to address his concern might be in the how to meet section by explaining the error should be specific as possible. We might also want to include and example that allows the AT to present the user with the information. I don't know of any AT today that extracts error messages and presents them in a cutom format for the person with the disability. I was going to add an example of this but Discussed in the 18 January 2007 telecon: Accepted by unanimous consent. http://www.w3.org/WAI/GL/2007/01/18-wai-wcag-minutes.html [partial accept] DONE add to the How to meet document intent section: "The error message should be as specific as possible." XML source updated 19 January 2007; Resolution: 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. 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. 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.; (Please make sure the resolution is adapted for public consumption)