Re: WCAG 2.0 comments: Issue 492

I'll address issues 492 and 496 together, since they are closely 
related, and they both seem to fit into Guideline 3.2.

I think the first statement in "Who benefits from Guideline 3.2" covers 
the issue of success feedback in a general sense, though the statement 
might be adjusted to include reference to situations where no feedback 
is provided.

"Providing consistent and predictable responses to user actions is 
important feedback for users. This lets them know that your site is 
working properly and encourages them to continue interacting with the 
content. When users receive an unexpected response, [ or receive no 
response,] they might conclude that something is wrong or broken. Some 
people might become so confused they will not be able to use your site."

An additional example for guideline 3.2 might be included to describe 
feedback:

"Example 4: Provide feedback when a form is submitted, or an action has 
been taken, to indicate the outcome. Outcome feedback might include 
success feedback to indicate that the submission or action was 
successful, warning feedback to indicate that potential  errors  may be 
present or that a decision must be made, and error feedback to indicate 
that the submission or action has failed and describe why it has failed 
and a course of action if appropriate."

The success criteria at level 2 in guideline 3.2 might reflect feedback 
"after" an extreme change, rather than exclusively "before" a change.

5. Explicit notice is given in advance of any extreme change of context.

should read

5. Explicit notice is given of any extreme change of context.

The primary reason for including success feedback with this guideline is 
to improve usability, more so than accessibility. It comes out of 
experience using a number of the commercial elearning systems. In most 
cases when users submit a form to add instructional content, or perhaps 
post a forum message, for example, they are required to navigate through 
the outcome page, or sometimes retrace their path,  to confirm that the 
submission was successful. In most systems error messages are used well 
if something goes wrong, but in virtually all cases no success feedback 
is provided, making it difficult for some users to verify the success of 
a submission without considerable effort. In each of these cases an 
extreme change occurs after an action has been taken, and warning users 
of such changes before they occur is often impractical (e.g. informing a 
user before taking an action that "when this form is submitted you will 
be redirected back to the forum message list" -- as opposed to feedback 
after the change that states "Your message was posted successfully. You 
may review it below" )

In relation to issue 496 regarding informing users "before" an extreme 
change, success feedback (or other feedback) will appear after an 
extreme change to indicate an outcome. The same strategy could apply to 
the popup window issue, indicating after the window has opened that an 
extreme change has occurred. We often use such a strategy by including a 
scripted "close window" link as the first feature in a popup window. For 
design reasons this is our preferred method of indicating new windows, 
reducing clutter on pages where stating  "opens in a new window" 
disrupts the visual appearance or the flow of information on a page.

The second example for guideline 3.2 might be adjusted to state before 
or after an action indicate that a change will occur, or has occurred:

"Example 2: a user is informed that a popup window *will* open, with a 
statement such as "link opens in a new window", or that a popup window 
*has* opened, with a statement/function such as "close window" as one of 
the first features in the new window.

The "close window" strategy is now fairly common practice, and most 
users will understand implicitly that it means a new window has opened, 
or will quickly learn the implicit meaning if they have not previously 
encounter the statement. 


greg

Wendy A Chisholm wrote:

> Hello Greg,
>
> Thank you for your comments on WCAG 2.0 [1].
>
> Issue 492 [2]
>
> Greg Gay writes:
>
> 2.5 Required criteria for this guideline applies to success feedback 
> as well as error feedback. When a screen reader user for instance, 
> submits  a form that performs a particular action, they will often 
> want to verify that the operation was successful. Without success 
> feedback it can be  very time consuming to make this verification.  
> "2. after a successful operation , provide the user with confirmation 
> feedback".
>
> Success feedback might have its own guideline (2.6,  though it might 
> fit as 3.4 (3c)) since it is fundamentally different from error 
> feedback, and error recovery.  However, both error and success 
> feedback could be consider  "graceful recovery". We distinguish 
> between error, warning, and success feedback in ATutor. Error messages 
> state the problem that occurred and provide courses of action. 
> Warnings state that a possible error has occurred and provide a means 
> to revert to a previous state our take an alternative course of 
> action. Success feedback provides simple confirmation (in most cases)
>
> ATutor Instructor Demo (see the feedback system as an instructor by 
> performing various tasks such as creating, updating, or deleting 
> content, modifying preferences, posting announcements....)
> http://www.atutor.ca/atutor/demo.php
>
> See "Learning from Your Mistakes" for more about fundamental cognitive 
> differences between error and success feedback
> http://www.ldrc.ca/projects/projects.php?id=23
> ===
>
> In response to Issue 496, I wrote [3]:
> This guideline was significantly rewritten in the March 11, 2004 
> Working Draft [3].  However, the draft does not include anything about 
> success feedback. It is not clear whether the recommendation to 
> include this feedback is something for the guidelines or techniques.  
> If you feel this should be included as a success criteria, please 
> propose an edit to the latest draft.
> ===
>
> Could you look at our latest draft [4] and write a proposed guideline 
> or success criterion?  I am happy to help you draft a proposal and am 
> available either by telephone or email, whichever you prefer.
>
> Thank you,
> --wendy
>
>
Appended:
Issue 496 [2]

Greg Gay writes:

3.4 An extreme change can be identified after the change has occurred,
such as a "close new window" link as the first feature of a popup
window, or presenting a feedback message after server side redirecting a
user from the content editing screen to the content display screen when
editing is completed (feedback like "content was successfully updated"
see guideline 2.5 above).

guideline should read "..., but not necessarily identical".

This guideline was significantly rewritten in the March 11, 2004 Working 
Draft [3].  However, the draft does not include anything about success 
feedback. It is not clear whether the recommendation to include this 
feedback is something for the guidelines or techniques.

Received on Sunday, 2 May 2004 11:14:42 UTC