Contact Us or call 1-877-932-8228


  • JavaScript is a programming language
  • Runs as a page is loaded and in response to events
  • OnClick works for both mouse and keyboard users, but OnMouseOver only works for mouse users

Rather than talk about scripts generally, it is easier to stick to JavaScript scripts that are by far the most popular on the web.

JavaScript is a programming language. It was developed by Netscape. As a "scripting language," it is interpreted by the browser "in place," that is, it isn't compiled into machine code as are high-level programming languages like C or C++.

Scripting languages are usually special purpose programming languages tailored to one specific application domain. The domain for JavaScript is the World Wide Web and HTML documents and objects. With JavaScript, you can interrogate almost anything that is being displayed in the current web page, and you can write new text and/or text effects in the current page.

The text of JavaScript programs is included in the script element. JavaScript code can be included in the HTML file for the current page, included as a link to an external JavaScript page (usually .js) or both (using two separate script elements).

When do JavaScript programs run? When are JavaScript functions executed? They run as a page is loaded, and they run in response to events. There are many such events, including keyboard events, like onKeyDown, and mouse events like onMouseOver. Perhaps the simplest and most familiar example is the click event, denoted onClick in JavaScript. It is triggered when the user clicks on an object or presses Enter. OnClick works for both mouse users and keyboard users, but onMouseOver only works for mouse users.

Here is an example of a JavaScript program:

Code Sample:

function increment() {
with( document.firstform) {
quantity1.value = parseInt(quantity1.value)+1; }

This function called increment adds 1 to the value of the input element named quantity1 in the form named firstform.

This function can be assigned to the event onMouseOver on an image or link or other element like this:

<span onMouseOver="increment()">This triggers increment</span>

Now every time the mouse passes over the text "this triggers increment" the specified input element (quantity1) will be incremented.

JavaScript Accessibility Concerns

  • To be accessible your page must "be usable" with scripting turned off
  • Two priority 1 checkpoints from WAI guidelines:
    1. Ensure pages are usable when scripts, applets and other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on alternative accessible pages
    2. Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies.

In this lesson, we will discuss the accessibility considerations that relate to JavaScript. These considerations are somewhat controversial and complex.

There are basically two kinds of things JavaScript programs do. The effects of JavaScript programs are either extra or ancillary, as in adding color effects when the mouse is moved over an object, or they are essential in creating the content on the page or taking action to submit a form.

The Web Accessibility Initiative of the W3C took the position in the 1999 Web Content Accessibility Guidelines that to be accessible your page must "be usable" when scripting is turned off. If your scripts are essential in creating content on your page, then probably your page won't be usable with scripts turned off.

Here are the two priority 1 checkpoints from the WAI guidelines that deal with scripts.

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.

Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies [Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2.]

The reason for the stringent requirement of Checkpoint 6.3 is simple enough. There are some people who use older browsers or text (non-graphical) browsers like Lynx. If JavaScript is playing any essential role on your web page, those people will not have access to your page content.

JavaScript functions that added some visual highlighting would certainly pass the Web Accessibility Initiative Checkpoints 6.3 and 8.1 since essential information is not lost when the JavaScript functions are turned off. On the other hand, JavaScript functions that are required for interacting with a form would fail the WCAG guidelines.

The Section 508 Standard

  • Functional text should be added to pages using scripting languages to display content, or create interface elements.

The Section 508 Web Accessibility Standard from the Access Board takes an approach that is less restrictive than that of the Web Accessibility Initiative guidelines. The idea advocated by the Access Board is to allow JavaScript so long as the results are accessible, that is, the material can be accessed by assistive technologies like screen readers and talking browsers:

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.

The requirement of §1194.22 (l) is to ensure that "functional text" is associated with any use of JavaScript.

An example (one which was a motivation for the way §1194.22 (l) was worded in the final rewrite of the Standards) where this is not done is a shopping site where there are pairs of arrows pointing up and down to increase or decrease the desired quantity of each item in a shopping cart. Screenshot of shopping site

Those up and down green arrows are, in fact, part of a small image map and the area elements of the map are coded like this:

Code Sample:

<map name="mpb24241">
<area coords="0,0,10,9" href="javascript:b(24241)" ... >
<area coords="0,11,10,20" href="javascript:qtydn3(24241)" ... >

Without the alternative text a screen reader will just read the value of the href. In this case the user will hear "javascript b 24241" and "javascript qtydn3 24241" respectively. There is text associated with the JavaScript, but it is not meaningful, i.e., not functional.

By the way, the functions b(x) and qtydn3(x) are similar to the sample increment( ) function that we saw as an example previously; b is increment and qtydn3 is decrement.

Functional text can and should be added to these areas. By inserting alternative text, alt="buy one more" and alt="buy one less" (for example) to the two areas, the necessary information is available to a blind user and the JavaScript is accessible according to the Section 508 standard.

If a web page uses scripts to fill contents of a form with basic default values, then most likely that aspect of the page will be accessible to contemporary assistive technology, specifically screen readers.

Comparison of JavaScript Requirements

  • Web Accessibility Initiative Guidelines
    • Direct and simple
    • JavaScript is acceptable as long as its application is not essential
  • Section 508 Standard
    • Neither direct nor simple
    • JavaScript is acceptable as long as the information is accessible

The Web Accessibility Initiative guideline for JavaScript is direct and simple. It is OK to use JavaScript so long as its application, what it does, is not essential. It is easy to test against the WAI guideline. Turn off JavaScript (see the next subsection) and test your web site.

In contrast, the Section 508 standard, recognizing the need for JavaScript in general, allows JavaScript so long as the information is accessible, i.e., readable with assistive technology. This standard is not direct and it is not simple. In what follows we will talk about different aspects of JavaScript use and where access problems arise.

Turn Off JavaScript in Your Browser

  • Check the usability of a page by turning off scripting

The easiest thing you can do to ensure compliance with the Section 508 standard that relates to JavaScript is to make sure your site complies with WCAG Checkpoint 6.3. So in order to check that your page is usable with scripting turned off, turn off JavaScript in your browser.

  • To turn off JavaScript in Internet Explorer, Version 5 or higher:
    • Tools / Internet Options / Security / Internet
    • Select Custom Level
    • Go to the scripting section and select the radio button to Disable Active Scripting
  • To turn off JavaScript in Firefox:
    • Tools / Options / Content
    • Uncheck Enable JavaScript

Of course if you are using the Web Accessibility Toolbar in IE, it is really simple. From the IE menu, choose Toggle JavaScript. The Web Developers Extension for Firefox also simplifies this process, Disable > Disable JavaScript > All JavaScript.

Accessibility Problems With Events

  • All basic functions must be available using only the keyboard
  • Select menus should not use onChange - use a submit button

If you attach JavaScript programs to events in the wrong way, your site may not be accessible. The key in this case, is whether or not your web page will function without the mouse. Can you use all the functions that you offer in your site with the keyboard?

The Section 508 Accessibility Standards include provisions relating generally to Information Technology; in addition to the web, the accessibility of Software, Telecommunications, Video and Multimedia, Self-Contained Units, and Desktop and Portable computers are all covered. A key provision in the Software Standards requires that all the basic functions be available from the keyboard.

When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually.

An example of such a keyboard issue is a select menu presenting list of pages like, Headlines News, Sports, Financial, Theater, etc. The select element is coded with an onChange event handler that gets executed when the selected value of the menu changes. The event handler opens the desired page. The reason it is becoming more common is that using the mouse is more efficient than having to make the selection and then click on a Go button.

The problem is that under some circumstances, if you cursor up or down in the menu after it gets focus, the onChange event handler is triggered and you are on the way to the new site before you even viewed the options. The CNN web site used to contain such an example. The select menu at the top left triggers the onChange event. CNN screenshot with open select menu

In the screenshot above, the "CNN Sites" select menu has been opened. Here is what the JavaScript coding looks like in this example:

<select ... OnChange="location=this.options[this.selectedIndex].value;">

A mouse user just opens the pull-down menu, then clicks on, say, CNN Europe. This causes the CNN Europe page to open.

However, when a keyboard user Tabs to the select menu with the "CNN Sites" entry and starts to move down the menu with the arrow keys, immediately the browser opens the next site ("CNN" in the screenshot above) because, keyboard movement in the menu is seen as a change (triggering the OnChange event) and the action is immediately taken. With this (accepted) keyboard interaction, the user would never be able to get past the first item - which, by the way is the page where all of this is taking place.

There is a keyboard alternative that I fear even today is not well known amongst keyboard users. After landing on the select menu, if the keyboard user opens the select menu with Alt+Down Arrow before moving down with the arrow keys, then the menu behaves correctly.

The way to completely avoid this problem is to include a submit button next to the select menu and use that to submit the request. (Remember to use alternative text if you use an image button.)

Unfortunately, web developers are not likely to know which events do not work with the keyboard because they use onChange events and only test with the mouse.

Note that it is not that onChange itself is bad or not accessible. For example, if the function assigned to the onChange event modifies a value in some other input control, then moving through the select menu with the arrow keys would make several changes, and presumably all of them would be OK. There is a problem when the onChange event handler loads a page.

At the Merriam-Webster site, if you want to look up a word in the dictionary, a select menu displays a list of up to six dictionary entries for the desired word. screenshot showing open select menu

This is achieved with the size attribute set to a value greater than one (in this case size="5"). With an onChange submission mechanism, the browser immediately submits the request when you use an arrow key with focus on the menu. This example is not accessible from the keyboard.

If you use select menus with size greater than one, then couple the select menu with a submit button; don't use the onChange event on the menu. The bottom line here is that you need to make sure your pages can be used by a person who is not using a mouse.

The issues of keyboard access on the web are huge in the new world of Web 2.0 and Ajax. Those problems make the select menu problem appear like a nit; and it is in comparison. At least there is a simple and clear choice to fix the select menu problem (Use a submit button) - not so for Web 2.0 (more below).

Different Roles for JavaScript Content

  • Four different kinds of JavaScript tasks:
    1. Direct Content
    2. Changes in Attributes
    3. Verification in Forms
    4. Hidden Content

At the beginning of the course we discussed the idea that web guidelines or standards served as a definition of "accessibility." The idea is that those guidelines tell you specifically what you must do and what you must not do on your page to ensure that your web site is accessible, i.e., usable by people with disabilities, especially those using assistive technologies. Those specific standards soften the requirement that you understand how folks with disabilities use your site or how their assistive technology works.

The JavaScript standard as stated by the Access Board creates a circularity in that it refers to being accessible to assistive technology. Thus, this standard is more difficult to interpret and follow than the WAI checkpoints that require that your page work with scripting turned off.

To help you understand the issues for scripting, I hope the discussion of four different kinds of JavaScript tasks or activities will help.

Direct Content

  • Scripts can write visible content directly to the document (document.write)
  • Meets Section 508 standard

Scripts can write visible content directly to the document, for example, with document.write. This is done when the page is loading.

A simple example of this is writing the message indicating the last date the page was modified so that when changes are made, the message updates itself - automatically.

Here's the code for this example.

Code Sample:

<script language="JavaScript"> d = new Date(document.lastModified); var year = d.getFullYear(); var day = d.getDate(); var month = 1+ d.getMonth(); document.write('\x3Cp\x3ELast updated: '+month+'/'+day+'/'+year); document.write('\x3C/p\x3E');

If this script was placed at the bottom of the page, then the script would write a "last updated" message there.

This kind of JavaScript content is accessible with today's assistive technology. It just is not a problem. It clearly meets the Section 508 standard. If you considered the last modified date to be essential information and wanted the page to comply with the WAI guideline for working with scripts turned off, then you would have to add the noscript element:

<noscript>Last updated: 10/19/2007</noscript>

Of course, in doing that you would have rendered useless the whole purpose of the script in the first place because you would have to remember to update that noscript code any time the page was changed! That statement is at the heart of the idea of providing an accessible alternative to inaccessible content; such alternatives are rarely updated when the "normal" content is updated.

Rarely is the noscript content useful.

Changes in Attributes

  • Event handlers can change images or attributes of content (ex. highlighting text)
  • Pages are still usable when JavaScript is turned off

Event handlers can change images or attributes of content, like highlighting or text color. Here is an example.

Code Sample:

<td bgColor="white" onMouseOver="bgColor='yellow'" onmouseout="bgColor='white'">
Text in a table cell.

When you move the mouse over the the table cell above, the onMouseOver event handler causes the background of the table cell to change from a white background to a yellow background. It changes back to white when the mouse moves out of the table cell.

This kind of JavaScript activity that involves colorful highlighting and other visual effects usually improves access for some while not hindering access for others.

If you have these kinds of JavaScript effects on your pages, they will still be usable when JavaScript is turned off and so will meet the strictest measure of accessibility for scripting.

Verification in Forms

  • Event handlers are often used to verify correct information in forms
  • Does not interfere with assistive technology

Script event handlers are often used to verify that information is entered correctly in forms. They can also enter or modify data as in the example at the beginning of this lesson. Tasks like this make things happen more quickly. You can tell when sites don't do this; you submit a form and the server returns an error page. In the worst case, you return to the page that has the form you are working on with the Back button and all your entries are gone. You fix error one, and after a wait, a second error page is sent. And so on. When the checking is handled at the client, it is quicker and more convenient.

Here is example code that will check to see if a user has entered a valid zip code:

Code Sample:

function CheckZip()
	var v=parseInt(s0);
	var s=v.toString()
	if ((!isNaN(v) && (v<99999) ) || isNaN(v)) {
		alert("Please enter a five digit numeric zip code);
		return false;

CheckZip can be assigned to the onSubmit attribute in the form element. The alert will inform the user of the error and, by returning false, the form will not be submitted. The function also clears the input field where the zip code is being entered.

This common kind of JavaScript transaction does not interfere with assistive technology. If your site requires such verification, or works more smoothly with it, just be sure that the event handlers are attached to events that work with the keyboard, like onSubmit and onBlur. Also be sure that a screen reader is aware of the error announcement. That is certainly true with CheckZip above because the error message is given as a JavaScript Alert; the clearest way to notify users of assistive technology that errors have occurred.

Assuming that you also do server-side form validation, your form will be usable with scripts turned off. So you won't be losing customers who are using text browsers or who have JavaScript turned off because of their security concerns.

I worked some with Gez Lemon at JuicyStudio on an article that takes the next step for form validation and dealing with errors in an accessible way. Here is his summary:

This article investigates a method of providing client-side form validation through the DOM, and ensures that it works as expected with screen readers. Modern screen readers work relatively well with scripting, but it's the extra steps required to inform screen reader users that the content has changed that needs addressing.

Hidden Content

  • Scripts often write content to internal frames, or write in a manner that the content is not visible or is hidden
  • Accessibility depends on the events used to trigger the exposing of hidden content
    • Ensure you can access the function with a keyboard
    • Ensure the content is available to assistive technology

Often scripts write content to internal frames or they write in a manner that the content is not visible or is hidden. Depending on user interaction, hidden content is made visible and, perhaps, other visible content is made invisible. Typical applications are the so-called "fly-over menus" and "plus-to-expand" navigation areas. It is with this hidden content that the issues of scripting and accessibility get really complicated.

The accessibility issues with this kind of scripting depend on the events used to trigger the exposing of hidden content. If the event is onMouseOver, which is typical of menus, then generally that content is not accessible.

An example is the National Science Foundation web site. Note in the screenshot, the pull-down menu resulting from the mouse being over the "Publications" menu item. (This is a screenshot of the NSF page in 2001. Today a similar idea is implemented in Flash.) screenshot of with open Publications menu with 6 items

The information in the pull-down menu (What's New, Most Popular, etc.) is not available to screen readers or keyboard users. When you tab into the NSF site, you get the main navigation menu links, About NSF, Funding, Publications, etc., not the sub menu links. This is not a problem for this site. If you follow the "Publications" link, which, itself is perfectly accessible, then the resulting page has those fly-over submenu links prominently available in a normal navigation position as can be seen with the following screenshot. menu items available as links

It is clear in this case that the fly-over menus offer a relatively minor convenience for sighted (mouse) users and a relatively minor inconvenience for those who are not using a mouse. Lacking access to those submenus does not make the site inaccessible. In fact, if the submenu links were in the tab order it would be bad. A menu system is only useful for keyboard users if you are not required to drill down at every point. It is not a good idea to implement JavaScript flyover menus so that every menu option is in the tab order.

If content is exposed with the onMouseOver event for a link, then for your site to meet the Section 508 requirement for scripts, that content must be available elsewhere, preferable prominently displayed on the page that is opened by that link.

Another kind of JavaScript content is "plus-to-expand." There are two different examples of this kind of content on Microsoft's MSDN site. The following screenshot shows both of the issues: screenshot of msdn site

There are two areas of JavaScript content on the MSDN page. The links down the left side starting "MSDN Subscriptions" down to "My links." I call these (for obvious reasons) "plus to expand" links. Then there are some links going across a blue bar in the center of the page starting with "Features" and ending with "Training & Events." These are like a tab control in Windows. When the user clicks on one of the tabs, say "News," the page of news items opens below the blue "tab" bar.

In both cases, the content already rests on your machine; JavaScript event handlers make the content visible. The following screenshot shows both the second of the left-hand links (MSDN Training) and the "News" tab activated. msdn site with 'news' activated

Notice how the links "Home," "Training Products," and "Training Offers" have opened up below "MSDN Training." Also the "plus" in a square graphic has changed to "minus" in the square. In addition, the screenshot shows that the tab "News" has been selected and the bottom center of the page now has new content corresponding to "News," instead of "Features."

If you have content like this, activated with the onClick event, then you must be sure that you can move with the Tab key to the links that do the expansion - and that the expansion works with the Enter key. Unplug your mouse! These keyboard tests are successful with the MSDN site shown above.

There are two things you must verify to be sure that you meet the Section 508 requirement for JavaScript accessibility for hidden content like this. Make sure you can access the function with the keyboard as we have discussed here, and make sure all the content is available to assistive technology.

On the MSDN site both conditions seem to be met; also all the hidden content is exposed when scripting is turned off. msdn, scripting off

The screenshot above shows MSDN with scripting turned off. Notice that all the "plus-to-expand" items are expanded (even though the "plus" is still there) and the blue bar of tabs is gone, replaced by only one "tab" - the Features tab. The other sections of content like "News" and "Columns" are farther down the page.

Perhaps, like MSDN, the data on your page is available when scripting is turned off. It is still much better to test your site with assistive technology with scripting turned on. Use a screen reader and/or a talking browser to verify that the links to unhide content can be activated and that the content is available to the blind user.