- From: <[email protected]>
- Date: Tue, 19 Apr 2005 17:17:48 -0400
- To: "WCAG " <[email protected]>
- 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: [email protected]
Received on Tuesday, 19 April 2005 21:15:52 UTC