- 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