Web Access Centre

JavaScript - Web Access Centre

Summary: JavaScript can be used as long as it is provided with an accessible alternative for uses of JavaScript for content and functionality.

• Rationale
• Techniques
• Testing tips
• Website Accessibility Initiative compliance
• Other pages about accessible scripts and forms

---

Rationale

JavaScript is a client-side scripting language that can be used to make HTML documents more dynamic and functional. Often, these scripts are used to create animation, change colours, create special effects or trigger events that modify the page or its content.

However, some JavaScript functions can cause problems for certain users. For example, people who use access technology such as screen readers or magnifiers may not realise that an event has been activated or that anything has changed, or may not be ready for it to change when it does.

If someone is using a browser that does not support JavaScript, or they have turned it off (some disable JavaScript because of concerns about security), script generated content will not be displayed. Providing alternative content using the <noscript> can often solve this. Unfortunately, many website designers fail to do this.

In addition, most JavaScripts and Java Applets rely on input from a mouse to activate them or interact with them. Increasingly we see the use of dropdown menus that only work when the user's mouse pointer is positioned over the start item. This is obviously inaccessible to people who cannot use a mouse or cannot see the mouse pointer.

JavaScript isn't the only client-side scripting language available; it is the most common one though, so we have used it to illustrate the techniques provided here. The techniques that apply to JavaScript apply equally to other client-side scripting languages, though obviously some of the syntax will differ.

Techniques

• Minimise the use of client-side scripting as far as possible. Where it is not essential, rely on HTML content instead.
• Include <NOSCRIPT> alternatives to client-side scripts. These should be inserted where the script itself would be active in the web page. This means that if scripting is not available, the <NOSCRIPT> content will be presented in its place.
• Descriptive text alternatives should be included for Java Applets and other objects. These should be inserted between the opening and closing <OBJECT></object> tags in the web page. Then, if the browser does not support the applet or object, the alternative content will be presented in its place.
• Provide keyboard controls for your scripts and applets. For instance, use the ONKEYPRESS event handler as well as the ONCLICK one.
• Provide user controls, if your script produces animation, a page refresh, or a timed event, to allow people to stop, pause or switch it off.

Here are examples of some common uses of JavaScript:

Image rollover effects

Simple image rollover effects will not normally cause any problems. As long as the image replacement doesn't contain any additional information, and is simply a visual effect (eg a menu button lighting up when the mouse cursor is held over it), this simple use of JavaScript should not have any impact on end users whose browser can't run the script.

Using JavaScript to duplicate browser functions

JavaScript is used on many sites to provide quick links which duplicate functions available in all browsers, such as "Print this page", "Back", "Close window" and "Email this page to a friend". There is no harm in using JavaScript in this way, since these are functions that all users can access through their standard browser commands, regardless of whether or not their browser can handle JavaScript.

However, it is frustrating for the user to be presented with these links when their browser doesn't support JavaScript, and so can't respond to these convenient functions. It's more user-friendly to use JavaScript to display these links, so that they will only be visible when the browser is able to run the script attached to the link.

Where appropriate, <NOSCRIPT> can also be used to prompt the user to take the required action. For example, to provide a "Close window" link:

<script type="text/javascript">
<!-- hide script from older browsers
window.write("<p><a href='javascript:window.close()'>Close window</a></p>")
// -->
</script>
<noscript><p>Close this window to return to the previous page.</p></noscript>

When coded along these lines, the "Close window" link will only be displayed when the browser can activate the JavaScript. In browsers where JavaScript is not supported, the alternative prompt in the <NOSCRIPT> element is displayed instead.

Opening links in a popup window

Using JavaScript to open a link in a popup window can make the link inaccessible to anyone whose browser can't run JavaScript. However if the link is coded correctly, this needn't be the case.

Examples of poorly coded links designed to open in a popup window:

<a href="javascript: function(url, window_name, parameters)">New page</a>

<a href="#" onclick="function(url, window_name, parameters)">New page</a>

In both of the above examples, the link will only work if JavaScript is supported. In the second example, it's possible that some keyboard users will be unable to activate the link, since it relies on the "onclick" event. While many browsers will activate the "onclick" event if the user tabs to the link and presses enter or the spacebar, it is better practice to include a non mouse-specific event to be certain that keyboard users are not being excluded.

Here is an example of a well-coded link designed to open in a new or popup window:

<a href="url" target="window_name" onclick="function(url, window_name, parameters)" onkeypress="function(url, window_name, parameters)">New page</a>

The example above shows a link which will function whether the user is using a mouse or the keyboard, and which will:

• Open in a popup window if JavaScript is supported by the user's browser and the browser can open links in a new window; or
• Open in a new full featured browser window if the user's browser doesn't support JavaScript but can open links in a new window; or
• Open in the current browser window if the user's browser doesn't support JavaScript and can't open links in a new window (or if the user has suppressed popup or new windows in their browser settings or through the use of additional software).

In addition, consider whether it is really necessary to open the link in a new window. If you decide that it is, you need to inform the user that the link may open in a new window.

Changing the page content on the fly

Another common use of JavaScript is to make changes to what is displayed on the page in response to the user holding the mouse cursor over an element on the page, or clicking on something on the page. For example, there might be several images on the left of the page, as the user holds the mouse cursor over each image, some text in the central area of the page will change.

This technique presents several problems:

• If JavaScript is not supported in the user's browser, they won't be able to trigger these content changes. So you should provide the same content in a <NOSCRIPT> element to ensure that these users can access all of the information.
• People who can't use a mouse may be unable to access the information. So as well as using the ONHOVER and ONCLICK events to trigger the change in displayed content you also need to include ONFOCUS and ONKEYPRESS event handlers.
• You need to consider those using very low-resolution screens or screen magnification software. They may not be able to see the entire page on screen at the same time. Will they even realise that additional content is being displayed elsewhere on the page when they hold the mouse cursor over a particular image?

You will need to provide cues or pointers to ensure that these users are aware of what is happening. Consider how users who can't see all of the page at once will be able to activate and maintain the changes to the page content as they pan from one part of the page to another.

One solution might be to have the content change is activated by clicking on the image rather than simply appearing when the mouse cursor is held over the trigger image, then it will still be visible when the user pans across to read it.

• Screen reader software is unlikely to be able to cope with changes to the page content unless the page is refreshed. In addition, a screen reader can only focus on one item on the page at a time (ie it presents the page content in a linear format), and won't be able to react to dynamic changes to content elsewhere on the page.

So you need to consider providing an alternative method to enable users to access the information being presented dynamically. Perhaps by providing additional links to the same information on another page.

Testing tips

Ensure that pages will make sense and can still be used when scripts, applets and objects are turned off or not supported by the user's browser.

• Accessibility toolbar – Checking that mouse only events are not present: Structure - Event Handlers. To ensure that navigation mechanisms all work without JavaScript: choose IE Options - Toggle JavaScript (switches support for JavaScript off and on) AND Doc Info - Identify Applets / Scripts [new window].
• Browser - to check that navigation doesn't rely on the use of a mouse: View - Source. Edit - Find - "script" and check for "click" or "mouse" only event handlers. OR Tools - Internet Options - Security - Custom level Scripting then check "Disable active scripting".
• Text browser - If links do not open or other functions are either not working or invisible, then JavaScript is used without accessible alternatives, as Lynx has no support for JavaScript.

Website Accessibility Initiative compliance

• 6.5 Ensure that dynamic content is accessible or provide an alternative presentation or page. Priority 2
• 6.2 Ensure that equivalents for dynamic content are updated when the dynamic content changes. Priority 1
• 1.1 Provide a text equivalent for every non-text element (eg via "alt", "longdesc", or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (eg animated GIFs), applets and programmatic objects, ASCII art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video. Priority 1
• 7.1 Until user agents allow users to control flickering, avoid causing the screen to flicker. Priority 1
• 7.2 Until user agents allow users to control blinking, avoid causing content to blink (ie change presentation at a regular rate, such as turning on and off). Priority 2
• 7.3 Until user agents allow users to freeze moving content, avoid movement in pages. Priority 2

For more information on techniques visit the Web Accessibility Initiative techniques page.

Other pages about accessible scripts and forms

• JavaScript
• Dynamic menus
• Forms
• JavaScript in forms
• Time outs, page refreshes and redirects

Back to Design & Build

For Web access centre updates email webaccess@rnib.org.uk

Content author: webaccess@rnib.org.uk

Last updated: 08/04/2008 18:38