WebAIM - Web Accessibility In Mind

E-mail List Archives

RE: Showing and hiding data

for

From: Terence de Giere
Date: Jul 26, 2003 3:08PM

Rachel wrote:

> I would like this application to be Section 508
> compliant. Are you saying the app must work with
> JavaScript turned off, in order to be Section 508
> 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?
Web developers working with JavaScript frequently use so-called JavaScript URL's as an easy way to invoke JavaScript functions. Typically, this technique is used as part of <a> anchor links. For instance, the following link invokes a JavaScript function called myFunction:

<a href="javascript:myFunction();">Start myFunction</a>

This technique does not cause accessibility problems for assistive technology.***
-------
[*** Added Note: This is clearly not correct. While it works with recent screen reader technology with a modern JavaScript enabled browser, it fails with a number of recent and older assistive technologies, with text browsers, and graphical browsers that do not support JavaScript. This is a bad example of the use of JavaScript with assistive technology. All the examples on this government page fail if JavaScript is off or not available. Under these conditions, these JavaScripted links are dead links.

Recent statistics from www.thecounter.com which summarizes visits to a large number of sites indicates 10 to 14 percent of visitors to public sites do not have JavaScript available. For various reasons, such as security, or the desire to avoid pop-up windows, etc., a small portion of users also deliberatly turn off JavaScript. That translates into JavaScript failure for that percent of visitors to a site. The W3C accessibility guidelines for user agents (browsers mostly) also require that turning off scripting is an option because on any given page, some or even all scripts may cause problems with rendering the page in 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:

"Client-side scripting on Web pages (e.g. JavaScript) can provide important dynamic information and can improve a site's aesthetics. But not every Web browser supports scripting languages equally and some assistive technologies may not read these scripts at all.

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]

A more difficult problem occurs when developers use images inside of JavaScript URL's without providing meaningful information about the image or the effect of the anchor link. For instance, the following link alsoinvokes the JavaScript function myFunction, but requires the user to click on an image instead of the text "Start myFunction":

<a href="javascript:myFunction();"><img src="myFunction.gif"></a>

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:

<a href="javascript:myFunction();"><img src="myFunction.gif" alt="picture link for starting myFunction"></a>

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:

<a title="this link starts myFunction" href="javascript:myFunction();"><img src="myFunction.gif"></a>

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.

Finally, the browser's status line (at the bottom of the screen) typically displays the URL of any links that the mouse is currently pointing towards. For instance, if clicking on an anchor link will send the user to http://www.usdoj.gov, that URL will be displayed in the status line if the user's mouse lingers on top of the anchor link. In the case of JavaScript URL's, the status line can become filled with meaningless snips of script. To prevent this effect, some web developers use special "event handlers" such as onmouseover and onmouseout to overwrite the contents of the status line with a custom message. For instance, the following link will replace the content in the status line with a custom message "Nice Choice".

<a href="javascript:myFcn();" onmouseover="status='Nice Choice'; return true;" onmouseout="status='';"><img src="pix.gif"></a>

This text rewritten into the status line is difficult or impossible to detect with a screen reader. Although rewriting the status line did not interfere with the accessibility or inaccessibility of the JavaScript URL, web developers should ensure that all important information conveyed in the status line also be provided through the "alt" attribute, as described above.

JavaScript uses so-called "event handlers" as a trigger for certain actions or functions to occur. For instance, a web developer may embed a JavaScript function in a web page that automatically checks the content of a form for completeness or accuracy. An event handler associated with a "submit" button can be used to trigger the function before the form is actually submitted to the server for processing. The advantage for the government agency is that it saves government resources by not requiring the government's server to do the initial checking. The advantage for the computer user is that feedback about errors is almost instantaneous because the user is told about the error before the information is even submitted over the Internet.

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.

onChange -- This event handler is very commonly used for triggering JavaScript functions based on a selection from within a <select> tag. Surprisingly, it presents tremendous accessibility problems for many commonly used screen readers and should be avoided. Instead, web developers should use the onClick event handler (associated with a link or button that is adjacent to a <select> tag) to accomplish the same functions.

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 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,
visit http://www.webaim.org/discussion/