Re: error technique - possibly for G2.5 L2 SC2

Sophia,

I like this as a simple example. But what if the form is more complex and
the user made multiple errors? I assume that each error would be listed at
the top with a link to the field in error. When the user selects a link to
navigate to the field and correct the error, he or she will then want to
return to the list of errors to proceed to the next one. Would we just
depend on the "Back" button for this or should we provide a more obvious
way to return to the list of errors?

Andi
andisnow@us.ibm.com
IBM Accessibility Center
(512) 838-9903, http://www.ibm.com/able
Internal Tie Line 678-9903, http://w3.austin.ibm.com/~snsinfo


                                                                           
             "Sofia Celic"                                                 
             <sofia.celic@nils                                             
             .org.au>                                                   To 
             Sent by:                  <public-wcag-teamc@w3.org>          
             public-wcag-teamc                                          cc 
             -request@w3.org                                               
                                                                   Subject 
                                       Re: error technique - possibly for  
             09/21/2005 05:44          G2.5 L2 SC2                         
             PM                                                            
                                                                           
                                                                           
             Please respond to                                             
                sofia.celic                                                
                                                                           
                                                                           




Hi all,

Attached is an example of a rendering of an HTML form that was not
successfully submitted (and an image that it uses). It can also be viewed
at http://www.nils.org.au/test/forms/format_error.htm for the time being.
The example is of an input error that occurred in amongst other "correct"
input and offers additional help for the form field that caused the input
error.
I think this example would fall under G2.5 L2 SC2 (If an input error is
detected and suggestions for correction are known and can be provided
without jeopardizing the security or purpose of the content, the error is
identified and the suggestions are provided to the user.)

This example is coded with HTML + CSS. I will also create a version of it
using Javascript to check the date format (if appropriate).

I've had a go at working backwards from the example to write out lists of
the techniques/concepts involved (a Javascript section is included even
though I haven't done a Javascript version of the example yet). I've also
tried to identify the features of it that would fall under the "pure
usability" umbrella to provide a complete picture and allow anything
missing to stand out more.

Please provide suggestions, thoughts, etc.

Many thanks,
Sofia


1.General techniques:

1.1 inform the user that an input error has occurred before presenting the
user with other content.

1.2 provide information about the number of items requiring change,
instructions on how to proceed and an itemised list of the requirements for
a successful form submission. Provide this information as the first item
(or one of the first items) of content (if this is the area of the
perceivable unit accessed by the user after the form submission). Emphasise
this content.

1.3 repeat information about each requirement in the context of its
particular form field or group. Emphasise this content.

1.4 provide a way for the user to skip from each item in the list of
requirements to its particular form field or group. (?and a way to shift
focus back to the summary?)

1.5 provide additional contextual help for the form fields or group
requiring change.


2. HTML techniques:

2.1 Include notification that an input error has occurred in the title of
the page ('title' element) and the heading for the content ('h1' element).

2.2 Emphasise information about the number of items requiring change and
how to proceed ('strong' element). Provide a list of the requirements in a
numbered list ('ol' element). Include an image (error icon) to pictorially
represent an item requiring attention.

2.3 Repeat information about each requirement in its context by including
an emphasised statement of the requirement ('strong' element) preceeding
the input error location. Include an image (error icon) to pictorially
represent an item requiring attention.

2.4 Implement anchor links ('a' element) for the user to skip from each
item in the list of requirements to its particular form field or group.

2.5 Provide additional contextual help for the form fields or group
requiring change, or a link to additional information ('a' element).


3. CSS techniques:

3.1 Use colour and increased font-weight to provide emphasis of content
for:
- information about the number of items requiring change, instructions on
how to proceed and an itemised list of the requirements for a successful
form submission
- information about each requirement in the context of its particular form
field or group


4. Javascript techniques:

4.1 Use client-side validation to provide contextual help for the form
fields requiring change.


Usability:
- fill in the information the user had already entered without input errors
- identify errors in a consistent manner
- use the same terminology in the error messages as that in the original
form fields
 (See attached file: alert_icon.gif)(See attached file: format_error.htm)