E-mail List Archives
Thread: RE: Showing and hiding data
Number of posts in this thread: 1 (In chronological order)
From: Terence de Giere
Date: Sat, Jul 26 2003 3:08PM
Subject: RE: Showing and hiding data
No previous message | No next message
> I would like this application to be Section 508
> compliant. Are you saying the app must work with
> compliant? I thought that wasn't a Section 508
> requirement? (I do know it is a WCAG guideline.)
The following Section 508 information is from the Access Board's web site. It may clarify some of the problems surrounding scripting. At one point I have added some information, because some of the information on this page is just not right. However there is some good information event handlers here.
http://www.access-board.gov/sec508/guide/1194.22.htm - excerpt from this page follows:
l) When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.
What accessibility problems can scripts cause?
Web page authors have a responsibility to provide script information in a fashion that can be read by assistive technology. When authors do not put functional text with a script, a screen reader will often read the content of the script itself in a meaningless jumble of numbers and letters. Although this jumble is text, it cannot be interpreted or used.
How can web developers comply with this provision?
This technique does not cause accessibility problems for assistive technology.***
Section 508 rules do seem to convey the idea that scripting is considered available with these rules but the wording for the scripting rule is so muddle headed that it is ambiguous exactly what is meant. For example, accessibility expert Jim Thatcher (www.jimthatcher.com) interprets this rule as having scripting available. Some government sites interprest the rule that a page should work with scripting off. For example the Navel Facilities Engineering Command (http://www.navfac.navy.mil/section508/l.htm) has the following statement about scripting for Section 508 on their web site:
To ensure our pages are accessible to all users, we need to ensure the information conveyed in our client-side scripts are available, even if the script is disabled."
The emphasis in the goverment rules appears to be for use with screen readers, with a graphical enviroment such as Windows. Accessibility specialist Michael Paciello of the Paciello group also told me once that the intent or bias of 508 rules appeared to be for screen readers.
If the site is not a public site, but in a controlled situation where the hardware, browser and browser settings, and assistive technology can be controlled, then this is a different matter. If the combination of hardware and software is known to work with these examples, then there is no problem. In a public situation, however, this assumption that scripting will always work is false.
Also, NOSCRIPT, the HTML element that can provide alternative information to a user without scripting, does not render in a browser that supports scripting and has scripting on. If the script cannot be interepreted by the assistive technology, NOSCRIPT is of no use to the user because its content will not render as long as scripting is on.
Therefore one needs to consider what happens when scripting is on, when it is off, and when it does not work properly. The simplist accessibility solution is to always assume client side scripting will fail, and design accordingly. This does not mean you have to avoid client-side scripting, but that a well thought out backup is available at all times in case it fails.
In particular, on-the-fly changes in a web page that occur as the scripted result of a user action are the kinds of scripts most likely to not be processed by a screen reader even if scripting is on. You should follow Julian Rickards advice here and test any document.write conditional changes in a page, or hide/unhide conditional changes with JAWS, IBM HPR, and perhaps Window-Eyes, to find out just how the informations renders or does not render. There are other kinds of technology as well, such a magnifiers, which normally would work, but some magnifiers (such as MAGic), in addition to enlarging the page for the reader, also will read out a page, and it is necessary to check whether the the speech synthesis also picks up a conditional change in the display.
[*End added note.*]
[continuation of Access Board's Section 508 information on scripting]
This type of link, as written, presents tremendous accessibility problems, but those problems can easily be remedied. The <img> tag, of course, supports the "alt" attribute that can also be used to describe the image and the effect of clicking on the link. Thus, the following revision remedies the accessibility problems created in the previous example:
Another technique advocated by some developers is to use the "title" attribute of the <a> tag. For instance, the following example includes a meaningful description in a "title" attribute:
This tag is supported by some but not all assistive technologies. Therefore, while it is part of the HTML 4.0 specifications, authors should use the "alt" tag in the enclosed image.
Web developers must exercise some caution when deciding which event handlers to use in their web pages, because different screen readers provide different degrees of support for different event handlers. The following table includes recommendations for using many of the more popular event handlers:
onClick -- The onClick event handler is triggered when the user clicks once on a particular item. It is commonly used on links and button elements and, used in connection with these elements, it works well with screen readers. If clicking on the element associated with the onClick event handler triggers a function or performs some other action, developers should ensure that the context makes that fact clear to all users. Do not use the onClick event handlers for form elements that include several options (e.g. select lists, radio buttons, checkboxes) unless absolutely necessary.
onDblClick -- The onDblClick event handler is set off when the user clicks twice rapidly on the same element. In addition to the accessibility problems it creates, it is very confusing to users and should be avoided.
onMouseDown and onMouseUp -- The onMouseDown and onMouseUp event handlers each handle the two halves of clicking a mouse while over an element -- the process of (a) clicking down on the mouse button and (b) then releasing the mouse button. Like onDblClick, this tag should be used sparingly, if at all, by web developers because it is quite confusing. In most cases, developers should opt for the onClick event handler instead of onMouseDown.
onMouseOver and onMouseOut -- These two event handlers are very popular on many web sites. For instance, so-called rollover gif's, which swap images on a web page when the mouse passes over an image, typically use both of these event handlers. These event handlers neither can be accessed by the mouse nor interfere with accessibility - a screen reader simply bypasses them entirely. Accordingly, web designers who use these event handlers should be careful to duplicate the information (if any) provided by these event handlers through other means.
onLoad and onUnload -- Both of these event handlers are used frequently to perform certain functions when a web page has either completed loading or when it unloads. Because neither event handler is triggered by any user interaction with an element on the page, they do not present accessibility problems.
onBlur and onFocus -- These event handlers are not commonly used in web pages. While they don't necessarily present accessibility problems, their behavior is confusing enough to a web page visitor that they should be avoided.
[end excerpt from Access Board's Web page.]
Terence de Giere
= EMAIL ADDRESS REMOVED =
Free 20MB Web Site Hosting and Personalized E-mail Service!
Get It Now At Doteasy.com http://www.doteasy.com/et/
To subscribe, unsubscribe, or view list archives,