W3C home > Mailing lists > Public > public-wcag-teamc@w3.org > September 2005

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

From: Makoto UEKI - Infoaxia, Inc. - <ueki@infoaxia.co.jp>
Date: Fri, 23 Sep 2005 02:30:50 +0900
To: public-wcag-teamc@w3.org
Message-Id: <20050923022233.76AA.UEKI@infoaxia.co.jp>

Andi,

In my opinion, we should provide a more obvious way to return to the
list of errors and should not depend on the "Back" button. 

Actually our website is using almost same pege design as the sample for
error notification page. But if there are multiple errors, we don't
present the way to go back to the list of the errors. We have to do
something... especially for the screen reader users.

Would it be enough for us to provide the internal link within the page
to go back to the list of the errors at the top of the page? To be more
usable, we'd better set the distination to the next error item.


Cheers,
Makoto


On Thu, 22 Sep 2005 09:48:04 -0500
Andi Snow-Weaver <andisnow@us.ibm.com> wrote:

> 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)
Received on Thursday, 22 September 2005 17:31:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:47 GMT