No Boundaries Logo

Web Accessibility Policy of the State of Maine

Back to Policy Table of Contents

Implementation Guidelines

13. Scripts

13.1 - Make sure that significant interactions can be performed with both keyboard and mouse.

Scripting languages, such as JavaScript, are simple programming languages that can be used within a web browser to automate certain tasks and enable pages to change and respond to user input. Scripts can trigger changes when the user performs specific actions ("events"). Some events are triggered by either mouse or keyboard actions. For example, an image can change color when the mouse pointer hovers over it (the onmouseover event).

Users with physical impairments may be able to use the keyboard but not the mouse. Individuals who cannot see the mouse pointer on the screen also use the keyboard for all interactions. Scripts that can only be triggered by the mouse are not usable by these individuals.

Whenever using a mouse-only event (e.g., onmouseover, onmouseout) to trigger a significant script action, also use the corresponding keyboard event (e.g., onfocus, onblur). Also make sure that keyboard events do not unintentionally trigger script actions. For example, keyboard users should be able to arrow through the choices in a <select> list without triggering each choice (e.g., onchange).

Ref: WCAG 6.4, 9.2, 9.3

13.2 - Make sure that essential content and functionality are available when client-side scripts are not fully supported.

Scripts are often used to dynamically show or hide the content that appears on a web page or to perform important functions, such as checking that entries in form fields are appropriate. "Client-side" scripts, such as JavaScript, are scripts that are run by the user's web browser. Client-side scripts must be supported by and compatible with the user's browser in order to work. ("Server-side" scripts, such as CGI, ASP, JSP, or PHP, run on the web server before the web page ever reaches the user's browser. Server-side scripts do not generally pose additional accessibility problems.)

Older assistive technologies and web browsers may not support client-side scripting at all. Even current assistive technologies may interact in unexpected ways with content that is displayed using scripts, such as by skipping text that is dynamically displayed or reading text that is dynamically hidden. Users need to be able to access the same essential content and functionality whether scripts are fully, partially, or not supported. It is not safe to assume that users with disabilities will have scripting support turned off.

Whenever scripts are used, it is the responsibility of the page developer to thoroughly test using assistive technologies to ensure that all information and functionality is accessible. If there is any doubt, err on the safe side by ensuring that the essential elements of the page do not rely on scripts.

Note: One approach to ensuring accessibility with scripts is to include a back-up method of providing the same information and functionality that does not require scripts. For example, if a client-side script is used to check an entry in a form field, a server-side script could make the same check. Similarly, if scripts are used for "drop-down" menus, the same menu choices could be provided in an appropriate location elsewhere on the current or subsequent page. Additionally, scripting features that are purely decorative and do not present any significant information or functionality do not need to be made accessible. (However, remember Guideline 8.1 - Avoid flickering, blinking, and unnecessary animation.)

Ref: WCAG 6.3; 508 l