W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2005

Possible Scripting Techniques to help with baseline evaluation

From: <Becky_Gibson@notesdev.ibm.com>
Date: Tue, 19 Apr 2005 17:17:48 -0400
To: "WCAG " <w3c-wai-gl@w3.org>
Message-ID: <OFF59092F0.A3C4AA94-ON85256FE8.00741DDD-85256FE8.00751849@notesdev.ibm.com>
This is a follow up to Michael's recent posting to the WCAG list about the 
impact of baseline on techniques [1].   

Here are some ideas for possible scripting techniques that could fit into 
our suggested baselines.  As you'll see, I borrowed several ideas from 
alistapart.com.  I tried to stay within Michael's description of "cannot 
be replicated in HTML" but being a JavaScript proponent I'm sure I've 
stepped over the bounds a bit!  Based on a discussion at the WCAG editors 
meeting I have placed these techniques in three groupings 
1) Script is not available in the baseline - this is the current set of 
script techniques 
2) Scripts that can enhance accessibility (scripting is assumed to be 
available in the baseline and turned on) 
3) Accessible scripting - examples of how to use scripts accessibly 
(scripting is assumed to be available in the baseline and turned on). 


No Scripting 

-current scripting techniques 

-accessible popups example from alistapart:  Accessible Pop-up Links[2]. 
This could also fits into the accessible scripting category 

Scripts to enhance accessibility: 

-how to use the onload event to set focus to a particular form element on 
the page.   

-how to catch the onchange on an input field, validate the contents and 
set focus to the next element in the form - or something similar that 
specifically sets focus to elements in some order 

-input assist to change the background color or border of the element with 
focus 
  
-input assist auto advance through fields.  Fore example, a US phone 
number input with 3 fields as you finish typing 3 numbers in the first 
field the cursor moves to the next field and after three numbers there 
jumps to the last field.  This one is likely to be controversial as I'm 
sure there are some people that dislike the auto advance behavior. 

-input assist to show a specific format in the field and user input over 
types the format with the actual value.  For example, a field for a US 
social security number that shows "###-##-####" - as the user types the # 
gets replaced by the actual input. 

-figure out how to create an accessible pop-up (NOT a new window) that can 
be made accessible.  I'm not sure how to do this, yet, but it could be 
used to provide more detailed information or help without leaving the 
page.   

-convert information provided via <link> elements into a select list on 
the page.  From alistapart.com entry:  Dynamically Conjuring Drop-Down 
Navigation [3] 

-provide alternative text sizing on the page (in combination with CSS). 
Here is an example for alistapart:  Power To The People: Relative Font 
Sizes 
[4]  Warning - it uses JavaScript uris :-) 

-formatting table rows to distinguish one from another.  This should help 
the readability of all users but particularly screen magnifier users if 
the table is wide.  Another alistapart example:  Zebra Tables[5] 

-image replacement using JavaScript.  JavaScript Image Replacement[6] 

-John Slatin has also suggested a technique that would (a) highlight text 
that the author has predefined as important and make the highlighted text 
available to screen readers as well.  This came up when looking at an 
instructional applicatoin -- there were buttons that allowed the user to 
see what the key terms in the text were. But all that happened at that 
point was to bring up another page that was identical to the first one 
except that now the key terms are highlighted-- clunky and inelegant. 
Seemed like it ought to be possible to do stuff by,e.g., changing the 
value of the visibility property, or change the font-weight or something 
so that screen readers *could* voice it (depending on user settings).

-Ben Caldwell suggested, "the use of mouseovers to render details about 
link destinations or definitions of glossary terms. 
I've seen this done well on a few pages, but can't seem to dig up a good 
example at the moment... Here's something that roughly approximates what 
I'm talking about - can be used to provide supplemental information that 
would aid in understanding of a page in some cases."  Not sure if this 
belongs in this category or the Accessible Scripting one.


Accessible Scripting 

-correct usage of onchange event on a select element that does not reload 
the page.   People often use this to prevent round trips to the server so 
the idea is to show how to do it properly.  I commented on this and posted 
and example when reviewing test cases:  
http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0465 [7] 

-show the use of a "Go" button next to a select rather than using the 
onchange event. The "Go" button will perform the action that the onchange 
would have performed. This is safer than the method above and can also be 
used when the action will load a new page or cause an extreme change of 
content. 

-although the use of blink is still debated, a JavaScript example of how 
to implement blink with a button to stop the blinking might be useful 

-show how to call a JavaScript function from the submit action of a form 
(current technique says do not do this) 

-give examples creating content using docment.createElement(). Although I 
don't have a good accessibility reason for doing this, it would be nice to 
give advice on how to do it correctly. Generally I recommend that folks 
create all the content at load time rather than "on demand" but I have 
successfully created new elements on the fly and have had screen readers 
work with it. 

-how to create onmouseover/onmouseout effects that work with the keyboard. 
For example changing a link image with onmouseover/onmouseout as well as 
with onfocus/onblur 

-show how to create a focusable element or element in the tab order using 
tabindex and how to add onclick and onkeypress events. Again, I don't have 
a good example of why you would want to do this and it has issues with 
browser support - only IE 5 and greater, Mozilla 1.8 and Firefox 1.1 

-how to hide/show information based on a specific input.  For example,  a 
select with a Go button that shows a different set of data or different 
form elements based on the selection made.  This is probably a bit too 
advanced, though, but it is something that web applications do. 

-an accessible clock or timer component 



[1] http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0010.html 
[2] http://www.alistapart.com/articles/popuplinks/ 
[3] http://www.alistapart.com/articles/dynanav/ 
[4] http://www.alistapart.com/articles/relafont/ 
[5] http://www.alistapart.com/articles/zebratables/ 
[6] http://www.alistapart.com/articles/javascriptreplacement/ 
[7] http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0465 

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: gibsonb@us.ibm.com
Received on Tuesday, 19 April 2005 21:15:52 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 23:39:36 UTC