Creating Accessible JavaScript

Overview of Creating Accessible JavaScript

Article Contents

1. Current page: Page 1: Overview of Creating Accessible Javascript
   1. What is JavaScript?
   2. JavaScript Accessibility Issues
      1. JavaScript that does not impact accessibility
   3. Comparison of JavaScript Guidelines
   4. Testing for JavaScript Reliance
      1. Disabling JavaScript
2. Page 2: JavaScript Event Handlers
3. Page 3: Other Issues
4. Page 4: JavaScript Alternatives
5. Page 5: Accessible JavaScript Summary

What is JavaScript?

This may best be answered by defining what JavaScript is NOT. First, it is not HTML. JavaScript does not use HTML tags or abide by any of the general rules of the HTML language. You can, however, use JavaScript with HTML on a webpage. Second, JavaScript is not Java. Although JavaScript is often called Java, the two are not the same. Java was developed by Sun Microsystems and is a stand-alone programming language. JavaScript, on the other hand, was developed by Netscape Corporation. Although similar to Java in syntax, JavaScript is not a stand-alone language; in order for JavaScript to work, it must be part of a web page that is being displayed in a browser that understands the JavaScript language. Sun's Java programming language can be implemented in webpages as a built in program, whereas JavaScript scripts are reliant upon the client (visitor's) computer in order for them to work.

Once again, JavaScript is not HTML or a version of HTML. It is a distinct, separate scripting language. HTML is read and processed by the web browser. When the browser reads JavaScript code within your HTML document, it processes the code, then displays any output within the web page. The computer reading the JavaScript must have a JavaScript interpreter, a program that interprets the script and runs it, and that interpreter must be enabled.

HTML, alone, creates very static pages. There is little user interaction and little by the way of dynamic content within a particular page. HTML cannot think; it does not have the capabilities to perform mathematics, store variables, or dynamically display content. JavaScript allows your web page to 'think'. Although many server-side scripting programs (such as PHP, JPS, ASP, or ColdFusion) have the ability to perform such functions, JavaScript can perform these functions within the client web browser. Because JavaScript is a scripting language, it allows developers to implement little applications into their pages. These programs may do things as simple as changing a graphic when the mouse rolls over it to something as complex as performing advanced mathematical formulas on user input.

JavaScript Accessibility Issues

JavaScript allows developers to add increased interaction, information processing, and control in web-based content. However, JavaScript can also introduce accessibility issues. These issues include:

• Navigation. Inability or difficulty navigating using a keyboard or assistive technology.
• Hidden content. Presentation of content or functionality that is not accessible to assistive technologies.
• User control. Lack of user control over automated content changes.
• Confusion/Disorientation. Altering or disabling the normal functionality of the user agent (browser) or triggering events that the user may not be aware of.

A web page containing JavaScript will typically be fully accessible if the functionality of the script is device independent (does not require only a mouse or only a keyboard) and the information (content) is available to assistive technologies. Unfortunately, there is no easy fix that can be applied to solve all accessibility problems associated with JavaScript. The only way to ensure JavaScript accessibility is by evaluating each individual script and devising a unique solution to the accessibility problem it poses. Developers must be familiar with the issues surrounding JavaScript accessibility and apply techniques to do one or both of the following:

1. Ensure the JavaScript is directly accessible
2. Provide an accessible, non-JavaScript alternative

JavaScript that does not impact accessibility

Just because JavaScript is utilized on a page does not mean that the page is inaccessible. In many cases, JavaScript can be used to increase accessibility. Additional information, warnings, or instructions can be given to users through JavaScript prompts. For instance, under the Section 508 guidelines of United States law, a user must be notified when a timed response is required and given sufficient time to indicate more time is required. Such functionality would be difficult with HTML alone.
JavaScript is sometimes used to create visual interface elements that do not affect accessibility. JavaScript is commonly used for image rollovers, where one image is replaced with another when the mouse is placed above it; for example, when a navigation item changes to display a shadow, glow, or highlight when the user mouses over it.

Place your mouse over the following image to see a JavaScript example that does not impact accessibility.

Problems

None. In this example, there is no important content or functionality introduced by the JavaScript. The swapping of images is purely cosmetic.

Solution

No additional accessibility techniques are required. Remember, the image itself must have alternative text (i.e., <img alt="home"...>). You can also accomplish image rollovers without using JavaScript - external link.

Such uses of JavaScript do not need additional accessibility features incorporated because important content is not displayed or functionality introduced by such scripting.
Making JavaScript accessible involves looking at the following issues. Each of these will be discussed in the next lessons.

• When using event handlers, use only those that are device independent (e.g., do not require the use of the mouse only).
• Content and functionality that is provided through scripting must be made accessible to assistive technologies.
• Web pages that utilize scripting must be fully navigable using a keyboard.
• JavaScript should not modify or override normal browser functionality in a way that may cause confusion.
• When JavaScript cannot be made natively accessible, an accessible alternative must be provided.

Comparison of JavaScript Guidelines

Section 508 of the Rehabilitation Act (in the United States) and the W3C Web Content Accessibility Guidelines (WCAG) 1.0 both address the accessibility of scripting elements. They require that the functionality and content of scripts be accessible to assistive technologies such as screen readers. Additionally, users must be given control over time-based content changes. There are, however, differences between the two accessibility guidelines. WCAG requires that content and functionality be accessible with scripting disabled and that users should be alerted if JavaScript changes the appearance or functionality of the browser window, whereas Section 508 only requires that the scripting be made accessible or that an accessible alternative is provided.

Testing for JavaScript Reliance

As mentioned above, your web pages should be fully functional with JavaScript disabled. This is required under Priority 1 of the Web Content Accessibility Guidelines. Section 508 does not require the page to function if JavaScript is disabled, but does require that the scripts themselves be natively accessible. This tutorial will teach strategies for making your scipts natively accessible and assumes that if you, as a developer, want to achieve a higher level of accessibility or comply with the Web Content Accessibility Guidelines, that you will also test your pages to ensure that they work with JavaScript disabled.

Disabling JavaScript

Follow the directions to disable or enable JavaScript in your browser. You can also determine if JavaScript is disabled. Test a JavaScript enabled web page and see if the content and functionality are accessible. Be sure to re-enable JavaScript when you're done.
Internet Explorer 6.X

1. Open Internet Explorer.
2. Select Tools > Internet Options.
3. In Internet Options dialog box select the Security tab.
4. Click Custom Level button at bottom. The Security Settings dialog box will pop up.
5. Under the Scripting category, enable/disable Active Scripting, Allow paste options via script and Scripting of Java applets.
6. Click OK twice to close out.
7. Click Refresh.

Netscape 7.X

1. Open Netscape.
2. Select Edit > Preferences.
3. Click the arrow next to Advanced.
4. Click Scripts & Plugins.
5. Check/uncheck Navigator beneath "Enable Javascript for".
6. Click OK.
7. Click Reload.

Opera 7.X

1. Open Opera.
2. Select File > Quick Preferences.
3. Check/uncheck Enable Javascript.
4. Click Reload. 

Overview

JavaScript can be processed using <script> elements and event handlers. The <script> element can contain JavaScript code directly:

<script type="text/javascript"> <!-- function doit(); --> </script>

or can open an external JavaScript (.js) file:

<script type="text/javascript" src="scripts.js">

The <script> element is processed when the page is loaded and requires no user intervention. The contents and functionality of the script processed within the <script> element must be directly accessible or an accessible alternative of the content and functionality must be provided.
Event handlers accompany existing HTML code and are triggered by a browser or user event - such as when the page loads, when the user clicks the mouse, or when the time is 8 p.m. Some event handlers are dependent upon use of a mouse or keyboard. These are called device dependent event handlers. Other event handlers are device independent and are triggered by both the mouse and keyboard or by other means. Using device dependent event handlers may cause the content to be inaccessible to someone that is not able to use the device that is required for that specific event handler.

onMouseOver and onMouseOut

The onMouseOver event handler is triggered when the mouse cursor is placed over an item. As its name implies, onMouseOver requires the use of a mouse, thus it is a device dependent event handler and may cause accessibility issues. onMouseOver, and its companion, onMouseOut, can be used, as long as any important content or functionality is also available without using the mouse.

Example 1

Place your mouse over the following image to see an example of onMouseOver. When the mouse is placed over the image of the word "Accessibility", another image appears in its place which presents the definition of the word "Accessibility".

<a href="page.htm" onmouseover="document.images['myimage'].src='imageoff.gif';" onmouseout="document.images['myimage'].src='imageon.gif';"> <img src="media/imageoff.gif" width="289" height="79" id="myimage" alt="Accessibility - The quality of being accessible, or of admitting approach; receptibility." /> </a>

Important
All of the examples in this lesson are coded to be XHTML 1.0 Strict compliant. XHTML requires lower-case event handler names (e.g., onmouseover instead of onMouseOver).

Try navigating to the image using the keyboard. Notice that the additional information does not display. The alternative text for the image provides the content displayed using the onmouseover event handler. This allows users who know how to access this alternative text to get the content, but is not a truly universal solution.

Problems

In this example, additional content is being displayed using onMouseOver. This content can only be viewed if the user uses a mouse to hover over the image. It is not available to someone who is using the keyboard to navigate through the page. The onMouseOver event handler cannot be made directly accessible to keyboard users. Thus, an alternative must be provided.

Partial Solution

Place the additional content in the alternative text of the image itself. This would work for screen reader users - the screen reader would read the alternative text. But for sighted users whose browser does not display alternative text for images or who do not know to mouse over the image to see the alternative text, this is not a viable alternative. Still, the image must have equivalent alternative text.

Solutions

In addition to onMouseOver and onMouseOut, use onFocus and onBlur. These actions will be triggered when the keyboard is used to navigate to and from a link that surrounds the <img> element.

<a href="page.htm" onmouseover="document.images['myimage'].src='imageon.gif';" onfocus="document.images['myimage'].src='imageon.gif';" onmouseout="document.images['myimage'].src='imageoff.gif';" onblur="document.images['myimage'].src = 'imageoff.gif';"> <img src="imageoff.gif" width="289" height="79" id="myimage" alt="Accessibility - The quality of being accessible, or of admitting approach; receptibility." /></a>

You must still provide the descriptive alternative text for non-visual users, but onFocus and onBlur will provide the visual image swap for users that are using a keyboard only.

Example 2

A common use of onMouseOver and onMouseOut is for fly-out or drop-down navigation systems. Place your mouse over the menu items below to view an example of drop-down menus. When the mouse is placed over the main menu items (onMouseOver), additional sub-menu items appear below. When the mouse is removed from the menu system (onMouseOut), then the sub-menus disappear.

Products

Services

Support

Problems

Additional content and functionality is being displayed using onMouseOver. In this example, JavaScript is controlling the display of Cascading Style Sheet elements within the page. The sub-menu items will only be visible if the mouse is placed over the main menu item. These items may not be available if JavaScript is disabled and may not be read by assistive technologies.

Solutions

When possible, use additional event handlers that allow keyboard navigation. When this is not possible, you must provide redundant navigation. This can be done one of two ways. First, provide links within the main content of the page to the pages displayed in the sub-menu navigation. This is often done as a list of categorized links at the bottom of the page. The downside of this approach is that the navigation is only accessible at the bottom of the page, which might be counter-intuitive to most users.
A second method of providing the redundant navigation is to add a standard href link from each main navigation items (e.g., Product, Services, etc.) to a separate web page that contains the sub-menu navigation items. If you select the Products, Services, or Support links above you will see an example of providing redundant navigation.

Example

<a href="productlinks.htm" onmouseover="SlideOutMenu();" onmouseout="SlideInMenu();">Products</a>

While this method does require the creation of an additional page and introduces an additional step, it also provides full access to the navigation elements in an intuitive way. This method also allows the sub-menu items to be accessible if JavaScript is disabled.

onFocus and onBlur

These event handlers are typically used with form elements, such as text fields, radio buttons, and submit buttons. onFocus is triggered when the cursor is placed on or within a specific form element. onBlur is triggered when the cursor leaves a form element.
Both of these event handlers are device independent, meaning that they can be performed with the mouse, keyboard, or other assistive technology. The actions that are performed as a result of these event handlers must be analyzed to determine if they cause accessibility problems. Typically, these events do not cause accessibility issues unless they are modifying the default behavior of the web browser or are interfering with keyboard navigation within the web page.

Example 1

Place your cursor within the following textbox to see an example of the onFocus event handler.
Enter your name :

<input id="fname" type="text" onfocus="alert('Enter your first name only');" />

Problems

None. Although the alert window may be distracting and unnecessary, it does not introduce any serious accessibility issues. The alert is triggered when the text box gains focus, either by using the keyboard or mouse. JavaScript alerts are read by most modern screen readers and can be used to increase the usability of forms by providing timely feedback, instructions, or cues. However, if JavaScript is disabled, then the alert will not be available at all.

Example 2

In this example, the onBlur event triggers JavaScript code that changes the functionality of the Web browser. Place your mouse into the following text box and enter a number between 1 and 10. Then press the Tab key or click the mouse outside of the text box to trigger the onBlur event which will validate the number you entered to ensure it is correct and present feedback regarding your answer. If it is incorrect, the text box will retain the cursor focus until you enter the correct number. In this example, you MUST enter the correct answer of '6' to allow the browser to navigate to other portions of the page.
Guess a number between 1 and 10?
Enter Answer:

<input type="text" id="input1" size="5" onblur="checkAnswer();">

Problems

Although the onblur event is device independent, it is being used to execute JavaScript code that makes the page difficult to navigate. The textbox maintains focus until the correct answer is given. This change in browser default behavior may be confusing and restricting. Also, the feedback is displayed in a different part of the page. Because focus is maintained within the text box, a screen reader will not be able to access the feedback text or any other part of the page until the correct answer is entered.

Solution

Do not force the focus to remain within the text box. Allow the user to navigate throughout the page. Display the feedback on another page after the form has been submitted (works without JavaScript) or display the feedback with a JavaScript alert (requires JavaScript). Try entering a letter into the textbox above to see a JavaScript alert feedback message.

onClick and onDblClick

The onClick event handler is triggered when the mouse is pressed when over an HTML element. onClick is intended to be a mouse dependent event handler. However, if the onClick event handler is used with hypertext links or form controls, then most major browsers and assistive technologies trigger onClick if the Enter key is pressed when the link or control has focus. In these cases, onClick is a device independent event handler. Nevertheless, the Enter key will not trigger the onClick event if it is used with non-link and non-control elements, such as plain text or table cells.
The onDblClick event handler is associated with the double click of a mouse on a selected HTML element. There is no device independent or keyboard equivalent to onDblClick, which should be avoided.

Example 1

The following link triggers a JavaScript confirmation box which allows you to confirm whether you want to view the page or not.
View this onClick example

<a href="page.htm" onclick="return confirm('Are you sure you want to view this page?');">View this onClick example</a>

Problems

None. The confirmation box is read by all major screen readers. By using the return JavaScript parameter, the link action is cancelled if the user selects No in the confirmation dialog box. If JavaScript is disabled, the link will work normally.

Example 2

The following text is styled to appear like a link (blue and underlined), but is plain text that has an onClick event which opens another document in the browser window. Use the mouse to click the following text.

View another onClick example

<p style="color:blue; text-decoration:underline" onclick="location.href='page.htm'">View another onClick example</p>

Problems

Because the text is not a hypertext link or form control, it does not receive focus while navigating with the keyboard. Because it does not gain focus, the keyboard cannot be used to activate the onClick event.

Solution

Use the onClick event handler on a link or form control instead of an element that cannot be accessed using a keyboard.

Example 3

A very common use of JavaScript is to validate form information. The following form will use JavaScript to allow you to confirm the information you have entered.
Enter your name in the following box, then press the Submit button.

Name:

<form action="page.htm" onsubmit="validate(); return false;">
<p><label for="yourname">Name:</label><input type="text" id="yourname" />
<input type="button" value="Submit" onclick="validate();" /></p>
</form>

Problems

The confirmation and alert dialog boxes that are triggered by the onClick event are accessible to browsers and assistive technologies that have JavaScript enabled. Validating the form information with a server side script and then displaying feedback on another web page allows you to bypass any problems that may occur in the JavaScript code and allows the form to validate if JavaScript is disabled. If JavaScript is used to validate the form, make sure that all form elements and functionality can be completed using the keyboard. Because the onClick handler is used with a form element, it is activated using both the mouse and the keyboard.

Note
Because most browsers will submit the form when the Enter key is pressed, the onsubmit event handler has been added to the <form> tag to ensure that the form will validate if the user does not activate the Submit button, but presses the Enter key while focus is in the text box. Also notice the required form label for the text box.

Example 4

This example also validates the form information, but feedback is displayed in another place within the page.
How many items are in a dozen? Enter the amount into the box below, then press the Check button.

Enter Answer:

<form action="page.htm" onsubmit="checkAnswer2(); return false;">
<p class="invis" id="answercorrect">Correct, there are 12 items in a dozen.</p>
<p class="invis" id="answerwrong">Incorrect. There are 12 items in a dozen.</p>
<p><label for="answerbox">Enter Answer:</label>
<input type="text" id="answerbox" />
<input type="submit" onclick="checkAnswer2()" value="Check" />
</p>
</form>

Problems

The feedback is not presented in a manner that would be accessible to some assistive technologies. In this example, JavaScript is modifying the display style parameters for elements within the page to make them visible or invisible based upon the response. The screen reader user would not be aware that additional content has suddenly appeared within the page.

Solutions

1. Validate the form information with a server side script, then display the feedback on another page.
2. Provide the feedback in a way that is accessible, such as a JavaScript alert or another form element.

onChange and onSelect

The onChange event handler is triggered when a form element is selected and changed (for example, when a radio button is initially selected or when the text changes within a text box). The onSelect event handler is processed when text is selected within a text field or text area. Although these event handlers are device independent and can be activated using the mouse, keyboard, or other device, the actions that are performed as a result of these event handlers must be analyzed to determine if they cause accessibility problems.

onChange example

The following drop-down menu form element is used for navigation. By selecting an item from the list, JavaScript will automatically open the specified page within the browser.

Note
In some browsers you may have to hit the Enter key or click on the page after selecting a menu item to activate the onchange event handler. Click on the Back button in the browser to return to this page.

Go to:

<script type="text/javascript">
<!--
function goto_URL(object) {
window.location.href = object.options[object.selectedIndex].value; }
//-->
</script>

<form action="page.htm" onsubmit="return false;">
<p><label for="selectPage">Go to:</label>
<select name="selectName" onchange="goto_URL(this.form.selectName)">
<option value="">Select a page:</option>
<option value="page.htm">Page 1</option>
<option value="page.htm">Page 2</option>
<option value="page.htm">Page 3</option>
</select></p>
</form>

Problems

The JavaScript causes the browser to go to a new page using onChange or when the user selects an item from the select list. If the end user is using a keyboard, the onChange event handler is executed for every item within the list. It is impossible for the user to directly select the last item in the list, as each previous item within the list will trigger the page change. The only way the user can select the last menu item is by navigating to the page for the first item in the list, then pressing the Back button, navigating to the second item, then pressing the Back button, and so forth until the last menu item is accessed.

Solutions

Rather than using the onChange event handler, allow the user to select the item from a list then select a button or submit the form to activate the script. When server-side scripting is used to process the form information and redirect the browser accordingly, there is no need for JavaScript at all. The following code demonstrates one method of fixing the onChange problem.
Select a page using the drop-down menu then select the Go! button. Click on the Back button in the browser to return to this page.

Go to:

<form action="page.htm" onsubmit="return false;">
<p><label for="selectPage2">Go to:</label>
<select name="selectPage2" id="selectPage2">
<option value="">Select a page:</option>
<option value="page.htm">Page 1</option>
<option value="page.htm">Page 2</option>
<option value="page.htm">Page 3</option>
</select>
<input type="button" value="Go!" onclick="goto_URL(this.form.selectPage2);" />
</p>
</form>


Using Device Independent Event Handlers

As mentioned previously, several event handlers are device independent, including onFocus, onBlur, onSelect, onChange, and onClick (when onClick is used with link or form elements). When possible, use device independent event handlers. Other event handlers are device dependent, meaning that they rely wholly upon a certain type of input. For instance, onMouseOver, onMouseOut, and onDblClick rely upon the use of a mouse. There are also some event handlers that are dependent upon use of the keyboard (onKeyDown, onKeyUp, etc.). Multiple device dependent event handlers can be used together to allow both mouse and keyboard activation of JavaScript. For instance, both onMouseOver and onFocus (as well as onMouseOut and onBlur) can be used to provide both keyboard and mouse activation of a script. Using multiple device dependent event handlers together as a method of implementing device independence requires a great deal of testing across different browsers and assistive technologies to ensure that accessibility is not limited in any way.

Dynamic HTML and Accessibility

Dynamic HTML (DHTML) is typically a combination of Cascading Style Sheets (CSS) and JavaScript. DHTML allows developers to display, hide, or move information based upon input from the user or pre-programmed commands. Many of the examples in this section have used DHTML. Most drop-down or fly-out menu systems found on Web pages also use DHTML. Because most of these DHTML elements are modified based upon mouse input, they are typically inaccessible to users who do not use a mouse. When DHTML is used, two items must be evaluated to determine its impact on accessibility:

1. Is the event used to trigger a change device independent? If the mouse is required, then it is not fully accessible.
2. Is the DHTML content or functionality itself accessible? If assistive technologies cannot adequately access DHTML triggered content or functionality, then it is not fully accessible.

Using document.write

Dynamic, constantly changing information is being written to the page in this example using the document.write command in JavaScript. In most cases, content that is written to the page using JavaScript is accessible to assistive technologies. However, if the dynamic content is constantly changing or otherwise interferes with navigation or browser functionality, then it may cause accessibility problems.

document.write example

The current time is displayed in the text box below. It updates and changes every second.

The current time is:

Problems

In this case, because the content is constantly changing and refreshing, a screen reader would not be able to read it and it may cause some confusion.

Solutions

When using dynamic information, you must first ask yourself if it is necessary and vital to the function or content of the page. If so, there is often a way to provide the content without using inaccessible JavaScript. For instance, you could write the current time to the page when it loads using a server-side script. Though it will not be constantly updating, it may suffice. You may also have the user select a link or button to go to another page that displays the current time from server side processing. Another approach that uses a more accessible implementation of JavaScript would be to provide a link or button that allows the user to display the current time at their request.

<input type="button"
value="Display the current time"
onclick="alert('The current time is ' + timeValue);" />

Pop-up Windows

Pop-up windows provide a unique accessibility problem. First of all, most usability experts would argue against the use of pop-up windows except in the most extreme of cases. If you must use pop-up windows, know that they introduce several very unique accessibility issues. For a visual user, it may be difficult to notice and navigate to the new window. For someone who is using assistive technologies, the new window may be annoying and confusing because the default behavior for the link has been modified. JavaScript implementation may make the new window difficult or impossible to resize or scale for someone using a screen enlarger. For someone who is blind, there is typically no indication that they are presently navigating in a new window. When the screen reader user attempts to return to the previous page by selecting the back button, it may be confusing to find that this does not work.

Pop-up example

Select this link to open a new window

<a href="popup.htm"
onclick="window.open(this.href); return false;">Select this...</a>

Note
If you are using software to block pop-up windows, you may need disable the software or select the link in a way that bypasses the pop-up blocker (typically Ctrl + click or Ctrl + Enter with the link selected).

In the example code above, the link will continue to work normally (i.e., in the same browser window) if JavaScript is disabled.
When using JavaScript to open new windows, you can modify the size and position of the new window. You can also add or remove functionality of the window, such as the ability to resize, display scroll bars, show tool bars, etc. Be very careful when changing the default behavior of the browser window. If a user has low vision and must enlarge the content, a small window that cannot be enlarged and does not display scroll bars would be very inaccessible. Someone with a motor disability may rely upon large tool bars to accurately control the web browser, so removing or modifying them may introduce difficulties for this user.
As you can see, there are many difficulties in both usability and accessibility that arise through the use of pop-up windows. Care must be taken in making the decision to use them. If they are used, thorough user testing of your implementation is vital to ensure accessibility. Always alert the user to the fact that a pop-up window will be opened.

Redirecting and Refreshing Browser Windows

When the page the browser is viewing suddenly changes or refreshes, the person viewing that page may become disoriented or confused, especially if that person is using an assistive technology. This is commonly done with page redirects when page content has been moved or updated. Section 508 requires that users be given control over time sensitive content changes. Do not automatically change or refresh the browser window without first alerting the user that the change will occur and giving him/her the ability to disable or postpone the change.

Using Pure CSS as a JavaScript Alternative

As mentioned previously, Cascading Style Sheet (CSS) parameters are often modified using JavaScript to create dynamically changing DHTML pages. However, with the advent of CSS version 2, much of the dynamic functionality available with JavaScript is now contained within the specifications for CSS itself. This allows the construction of interactive and dynamic navigation and layout elements without the need for JavaScript events. You can create drop-down menus, interactive images, and other exciting features in Web sites without worrying about device dependent event handlers. However, the new CSS standards are not fully supported in modern browsers, namely Internet Explorer.
Also, screen readers do not have great CSS support, especially when presented with content that can be made visible or invisible using either the display:none or visibility:hidden styles. Many screen readers do not read content that is assigned these styles even though the content is still part of the underlying structure of the page. Until there is better CSS support in both web browsers and assistive technologies, using CSS alone to produce dynamic content should only employed with much testing in a variety of browsers and screen readers.

Introduction

Whenever JavaScript cannot be made directly accessible, an accessible alternative must be provided. Also, many user agents, such as web-enabled cell phones and PDA's, do not yet utilize JavaScript. There are several ways you can provide accessible alternatives when the scripting cannot be made accessible or when the end user does not have JavaScript enabled.

Server-side Processing

In many cases, the functionality provided by JavaScript can be duplicated by server-side scripting. For example, JavaScript is often used to validate form elements before a form is posted. Instead of implementing such JavaScript programming and its accompanying accessibility techniques, you could use a server-side script to validate the form elements. JavaScript is often used to write dynamic information to a web page, such as the current date and/or time. Again, using a server script or server-side include negates the need for additional accessibility implementation.

Using the <noscript> Element

Making JavaScript natively accessible is very important. However, in some cases, the end user may not have JavaScript enabled or may be using technologies that do not support JavaScript (e.g., cell phone, PDA, etc.). In such cases, you can provide non-JavaScript alternatives to user's who cannot or choose not to view JavaScript content.
When JavaScript is used within a Web page, the most straightforward way to provide an alternative for the JavaScript-generated content is to provide content within the <noscript> element. The <noscript> element can be used within your page to display content in browsers that do not support or have disabled JavaScript. However, if JavaScript IS enabled the <noscript> element is ignored.

Important
Providing an accessible alternative within the <noscript> element for an inaccessible script will not make the page accessible. The <noscript> content will only display if JavaScript is disabled. Most screen reader users have JavaScript enabled, and will thus encounter your inaccessible script and not the <noscript> content.

The <noscript> element provides alternative text for the JavaScript. If the content or functionality of the script needs an accessible alternative when JavaScript is disabled, then you need <noscript>. The <noscript> content should ideally contain the equivalent content or functionality that is provided by the script. However, this is often not possible. It is not sufficient to simply indicate, "Your browser does not support JavaScript." This does nothing to make the content accessible. You may, for example, provide a link to an accessible HTML alternative or to a page that utilizes server-side scripting instead. Or, at very least, describe the type of content that would be displayed if JavaScript were enabled.
<noscript> should be used anytime alternative or non-javascript content or functionality is required.

<script type="text/javascript">
<!-- document.write("The current time is " + currenttime) -->
</script>
<noscript>
<!-- link to page that displays time from server-side script -->
<a href="time.htm">View the current time</a>
</noscript>


<noscript> example

In the following example, two form buttons are provided within the HTML code. If you have JavaScript enabled, the document.write command within the <script> element will display the first button. If this button is selected, it triggers a JavaScript function that may be used to validate and submit the form using additional JavaScript within the page. If JavaScript is not enabled, then the button contained within the <noscript> element is displayed, which could submit the form to a server-side processing script, which would provide the form validation and feedback.

Username:

<script type="text/javascript">
<!--
document.write('<input type="button" value="Submit" onclick="validateForm();" />');
-->
</script>
<noscript>
<p>
<input type="submit" value="Submit">
</p>
</noscript>


Overview

JavaScript allows developers to add increased interaction, information processing, and control in web-based content. JavaScript can also cause accessibility problems by limiting navigation using a keyboard or assistive technology, presenting content or functionality that is not accessible to assistive technologies, limiting user control over automated content changes, and modifying the normal functionality of the browser. When faced with JavaScript accessibility issues, you must do one of the following:

• Ensure the JavaScript is directly accessible
• Provide an accessible, non-JavaScript alternative

JavaScript is often used to make cosmetic or other content changes that do not affect accessibility. Content written to the page using JavaScript is accessible if:

• Device independent event handlers are used.
• JavaScript enabled content and functionality is accessible to assistive technologies.
• Scripted pages and elements are navigable using a keyboard.
• The normal browser functionality is not modified in a way that may cause confusion or inaccessibility.
• An accessible alternative is provided when JavaScript cannot be made natively accessible.

JavaScript Event Handlers

There are two types of JavaScript event handlers - device dependent and device independent. When implementing event handlers, you must either use a device independent event handler or use multiple device dependent event handlers to accommodate all users. Below is a list of common event handlers and their associated accessibility issues.

onMouseOver and onMouseOut

Device dependent (require the use of a mouse)

Ensure important content or functionality is not introduced with these event handlers

Use in conjunction with the onFocus and onBlur event handlers to allow keyboard accessibility

Provide an accessible alternative if the content or functionality cannot be made natively accessible

onFocus and onBlur

Device independent (work with both keyboard and mouse)

Test to ensure that accessibility is not affected

onClick and onDblClick

Device dependent (require the use of a mouse)

onClick is activated by keyboard input when used with links and form elements

There are no device independent or keyboard accessible equivalents to these event handlers

Functionality and content provide by the onClick event handler must also be made accessible

onChange and onSelect

Device independent (work with both keyboard and mouse)

Functionality and content provide by the onChange and onSelect event handlers must also be made accessible

Drop-down menu navigation items that are triggered with onChange are not fully keyboard accessible

Dynamic HTML and Accessibility

Dynamic HTML (DHTML) is a combination of JavaScript and Cascading Style Sheets (CSS). By its very nature, DHTML can present dynamically changing content. DHTML is often triggered by user interactions, such as moving the mouse. When implementing DHTML, you must ensure that the DHTML is triggered in a device independent way and that the content and functionality provided by the DHTML is also accessible.
JavaScript can also be used to write dynamic content to the web page. In most cases, this content is accessible, unless the content is constantly changing or is in any other way interfering with accessibility of the page.

Pop-up Windows

The default behavior of the web browser and certain HTML elements can also be affected by JavaScript. Pop-up windows can be triggered by JavaScript or by JavaScript event handlers. If the user is not alerted to the fact that a pop-up window is opening, they may become confused or disoriented by the unnatural behavior of the Web browser. Further modification of browser windows to remove scroll bars, status bars, menu bars, or tool bars may also cause accessibility problems. Use pop-up windows with care and if they are used, always alert the user to this fact. The user must also be alerted when JavaScript is used to automatically perform browser functions, such as redirecting, refreshing, or automatic scrolling. In all cases, user testing and testing with assistive technologies can provide valuable feedback regarding accessibility of specific JavaScript implementations.

JavaScript Alternatives

There are many ways to provide alternatives to JavaScript. Newer versions of CSS allow much of the behavior of JavaScript to be replicated using CSS alone. Drop-down menus, navigation bars, and interactive images can all be developed without relying on JavaScript. However, the implementation of CSS across browsers and assistive technologies is varied and problematic. When JavaScript itself cannot be made natively accessible, you must provide an accessible alternative. This can be done by replicating or replacing the JavaScript behavior with server-side processing. You can also provide <noscript> content which will be accessible when JavaScript is disabled or not available to the end user.

Standards and Guidelines

The following standards and guidelines apply to JavaScript:

Section 508 of the Rehabilitation Act §1194.22:

• (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.
• (n) When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.
• (p) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.

W3C Web Content Accessibility Guidelines (WCAG) 1.0:

• 6.3 (Priority 1): Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.
• 6.4 (Priority 2): For scripts and applets, ensure that event handlers are input device-independent.
• 6.5 (Priority 2): Ensure that dynamic content is accessible or provide an alternative presentation or page.
• 7.4 (Priority 2): Until user agents provide the ability to stop the refresh, do not create periodically auto-refreshing pages.
• 7.5 (Priority 2): Until user agents provide the ability to stop auto-redirect, do not use markup to redirect pages automatically. Instead, configure the server to perform redirects.
• 8.1 (Priority 2): Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies.
• 10.1 (Priority 2): Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user.