How do scripting languages affect accessibility?

Date Updated: 
01/24/13

Scripting languages are becoming increasingly popular on the web, because they can be used to make web pages more dynamic and interactive. There are two types of scripting languages: server-side and client-side. Server-side scripting performs all of its processing on the web server and delivers a final product (the web page) to the user's browser. Server-side scripting does not, in and of itself, present accessibility problems. Like all web content, however, server-side scripts must produce content that follows principles of accessible design.

In contrast, client-side scripting is scripting that does all of its processing on the user's own computer. It is commonly used to create pop-up windows, instant-redirect pulldown menus, shopping-cart calculations, and mouseover effects (i.e., menus or images that change when the user's mouse passes over them). Javascript is the most popular client-side scripting language.

Whether client-side scripts yield accessible content depends largely on how they're used and whether the user has technology that supports them. Older versions of popular browsers do not support client-side scripting, and newer versions allow users to turn off script support (many users do so because of security concerns or to turn off annoying features such as pop-up ads or scrolling tickertapes). The answer to the question of whether script-generated content is supported by assistive technology depends on the intended function of the script and on the technique used to deploy that function. For example, if the intended function is to display a submenu when the user mouses over a particular link, then this function is inaccessible to people who aren't using a mouse. If, on the other hand, the intended function is to display a submenu when a particular link has focus (e.g., where pointed to with the mouse or tabbed to with the keyboard), then the function itself may be accessible. However, particular techniques for deploying this function may be inaccessible to people using assistive technology such as screen readers.

There continues to be much discussion among web accessibility experts about correct techniques for delivering accessible script-generated web content. However, there is general agreement on many of the basic principles involved. The Web Content Accessibility Guidelines 1.0, which are defined by the World Wide Web Consortium (W3C), include four guidelines that specifically address scripting issues:

  • 6.3 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. [Priority 1]
    For example, ensure that links that trigger scripts work when scripts are turned off or not supported (e.g., do not use "javascript:" as the link target). If it is not possible to make the page usable without scripts, provide a text equivalent with the NOSCRIPT element, or use a server-side script instead of a client-side script, or provide an alternative accessible page as per checkpoint 11.4.
  • 6.4 For scripts and applets, ensure that event handlers are input device-independent. [Priority 2]
  • 6.5 Ensure that dynamic content is accessible or provide an alternative presentation or page. [Priority 2]
    For example, in HTML, use NOFRAMES at the end of each frameset. For some applications, server-side scripts may be more accessible than client-side scripts.
  • 9.3 For scripts, specify logical event handlers rather than device-dependent event handlers. [Priority 2]

The following additional resources explore accessible scripting in greater detail, including specific examples of typical scripting functions and techniques:

The following AccessIT Knowledge Base articles might also be of interest: