13. Scripting and Applets

13.1 Pages usable when scripts, applets and other programmatic objects turned off

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

Guide to this standard

Scripting as referred to here is Client-side scripting.

Scripting languages should only be used where required. A simple rule of thumb regarding the usage of scripting or applets is to ask:

“is this really necessary in the web site?” and

“can the functional end objective be met without scripting and/or applets?”

If scripting (or an applet) must be used, then:

• All information and services on a government web site must be available whether or not scripting is available to the user, and
• Text-based alternatives are available.
• If using Javascript, adopt the principals of “unobtrusive Javascript”. This is principally enhancing usability without decreasing accessibility with the use of Javascript.

Where active scripting is used, it should conform to the ECMAScript standard, rather than a proprietary standard, and should use the W3C Document Object Model (DOM). This is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents.

This standard covers the W3C WAI checkpoint 6.3 (http://www.w3.org/TR/WCAG10-TECHS/#tech-scripts) for NZ government agencies.

Rationale for this standard

Some organisations and individuals do not allow scripts to be run in their browsers, and some browsers do not understand some types of scripting. Scripting languages (particularly JavaScript) are abused creating a perception of insecurity and/or invasiveness among some web users.

Scripting can reduce accessibility in certain circumstances and can ‘confuse’ assistive technologies such as screen readers. Dynamic drop-down menus in particular are known to cause significant accessibility problems for people with motor or visual impairments, for example when screen magnifiers are used.

Applets and/or support for applets may require downloads, which are either disabled for a user community or which a user simply may not wish to download (and run through possible subsequent installations) for one or more reasons (excessive time to download with a slow connection, potential security issues etc.)

A web browser user generally has full control over any client-side scripting, giving the potential for manipulation of the script.

Most browsers provide a means to disable support for scripting, thus reinforcing the need not to have reliance on scripting.

13.2 Alternative event handlers and device dependence

For scripts and applets, ensure that in the absence of a mouse or equivalent device - have an alternative event handler and specify logical event handlers rather than device-dependent event handlers.

Guide to this standard

Event handlers are input device-independent.

It is so easy to only consider the common “point and click” devices (i.e. mouse) in web design and development and then have a web site primarily dependent on the specific functionality of such devices.

This standard covers the W3C WAI checkpoints 6.4 ( http://www.w3.org/TR/WCAG10-TECHS/#tech-keyboard-operable-scripts) and 9.3 ( http://www.w3.org/TR/WCAG10-TECHS/#tech-device-independent-events) for NZ government agencies.

Rationale for this standard

The principal consideration here is with navigation devices. Design and development consideration should be to generic navigation, not a specific navigation device (i.e. a mouse). Users who do not and/or can not use such devices are disadvantaged if a site has been designed with dependence on specific device types (such as a mouse for navigation). Likewise, the corresponding event handlers should not be device specific.