RE: [TECHS] Techniques issues summary for Guideline 2.5

I did some work on 2.5 here:

 

http://www.eramp.com/david/general/

 

There are 11 techniques that I gathered from various experts here in Canada

 

Regards

David MacDonald

 

...access empowers people.

            .barriers disable them.

 

www.eramp.com <http://www.eramp.com/>  

 

  _____  

From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of Becky_Gibson@notesdev.ibm.com
Sent: Monday, May 23, 2005 6:11 PM
To: w3c-wai-gl@w3.org
Subject: [TECHS] Techniques issues summary for Guideline 2.5

 


At the May 18, 2005 Techniques Task Force meeting, I took an action item to
create an issue summary for GL 2.5. My initial work was fairly easy since I
can not find any General, HTML, CSS, or JavaScript  techniques that map to
GL 2.5.  The harder part of the work will be to propose techniques for this
guideline.   

According to the minutes from the WCAG WG teleconference on May 19,,2005,
the following two SC for 2.5 were accepted: 
Level 2 Success Criteria for Guideline 2.5

1. If an input error is detected, the error is identified and provided to
the user in text.

2. If an input error is detected and suggestions for correction are known
and can be provided without jeopardizing security or purpose, the error is
identified and the suggestions are provided to the user in text. 

I think it may prove difficult to provide HTML only examples for error
correction, does anyone have any ideas? I suspect authors using XHTML and
HTML will either do this via  a round trip to the server or will use
JavaScript.  Would a round trip to the server and then specific markings in
the HTML to specify the error fall under general or HTML techniques?  Any
ideas would be appreciated. 

One simple JavaScript technique for L2 SC 1 would be simple validation that
a text field contains an entry and then using an alert to notify the user.
A combination CSS and JavaScript example would be to change the color or add
an outline to an error field and set focus to it.  Although, setting focus
to the field may be programmatic in some screen readers.   

There are two open bugzilla entries. 
 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1249> #1249 [1] is a
JavaScript technique that I submitted in October 2004 which shows and
focuses an  error message in the vicinity of a field containing a found
error.  The error text is given focus to draw it to the user's attention.
This technique works with JAWS and WindowEyes but not with Home Page Reader
so it might not be appropriate. 
 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1250> #1250 [2] Is a
textual description of a similar type of error identifier (I think Chris
Ridpath and I both took action items during  a techniques call to submit a
bugzilla entry for this idea).   
<action> merge the information from #1250 into #1249 and close #1250.
</action> 


[1] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1249 
[2] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1250 

Becky Gibson
Web Accessibility Architect
                                                      
IBM Emerging Internet Technologies
5 Technology Park Drive
Westford, MA 01886
Voice: 978 399-6101; t/l 333-6101
Email:  <mailto:gibsonb@us.ibm.com> gibsonb@us.ibm.com