2.19 Use logical event handlers in scripts
Contents
WAI checkpoint 9.3
Full WAI text: "For scripts, specify logical event handlers rather than device-dependent event handlers." Scripts are pieces of functionality written in languages other than HTML, to provide dynamic or interactive behaviour ranging from simple visual effects to mini applications.
Some examples are enhanced functionality like pop-up menus coded in DHTML, form input validation routines written in JavaScript and interactive applications such as tax calculators or games written in Java or Macromedia Flash.
An event handler is a script that is invoked when a certain event occurs (e.g, the mouse moves, a key is pressed, the document is loaded, etc.).
You must ensure that event handlers, which activate interactive features delivered through scripts and applets, can be activated and controlled using the widest range of input devices, including the mouse, keyboard, microphone, Braille devices, head wands or other pointing devices.
Some event handlers produce effects which are purely visual but others are used to complete critical tasks such as submitting the contents of a form, completing a calculation or sending a message. Event handlers critical to completing a task should always be input device independent.
Rationale
Interfaces, which do not provide flexibility in the type of device which the user must rely on to input information or to receive outputs, are inherently inaccessible. A laptop user may choose to work without a mouse and favour the keyboard instead. If this were the case and interactive features on a site required "drag and drop" interactivity as the only means of interaction, the site would be unusable. Similarly, a site delivered through a kiosk or public access terminal with only a touch screen interface would be unusable if you can't see the screen.
This issue is not confined to inputting information. It is also important to provide device independent output. A screen reader user may be able to open a DHTML menu but if they receive no feedback on the names of the links they are selecting, the menu is unusable. Similarly, they may be able to open a Javascript tax calculator and input data but if the output is not compatible with a speech synthesiser, then it is not device-independent.
Developing interfaces which provide input device independence facilitates porting the site to the widest range of computing devices, including mobile handsets, PCs, and Interactive Voice Response systems (IVRs).
Screen reader users rely entirely on the keyboard for interacting with websites. Failing to support the keyboard as an input device will make the site unusable to them. Other users may use voice input for hands-free operation in a busy office, or if they have dexterity limitations.
Directions and Techniques
Separate structure and presentation
Design the structure of documents or web pages before thinking about how they will be presented to the user. Refer to WAI recommended techniques for separating structure and presentation
If you must use device-dependent attributes, provide redundant input mechanisms
In HTML 4.01, application-level event attributes are "onfocus", "onblur" (the opposite of "onfocus"), and "onselect". Note that these attributes are designed to be device-independent, but are implemented as keyboard specific events in current browsers. Otherwise, if you must use device-dependent attributes, provide redundant input mechanisms (i.e., specify two handlers for the same element):
- Use "onmousedown" with "onkeydown"
- Use "onmouseup" with "onkeyup"
- Use "onclick" with "onkeypress"
Note that there is no keyboard equivalent to double-clicking ("ondblclick") in HTML 4.01.
If you use Java to create applets, consult the Java Look and Feel Guidelines from Sun
Java has inherent accessibility features. Ensure that you have provided for input device independence using them. Refer to Sun's guidelines on accessibility features provided in Java for details on using them.
Refer to IBM Accessibility Centre for more information on scripts
The IBM Accessibility Centre provides more information on scripts and accessibility
How you could check for this:
Disconnect the mouse and try to navigate with the keyboard
Assuming that you know how interact with a website using keyboard only navigation, this simple test will very quickly show you if it is possible to navigate or interact with the site using an input device other than the mouse. Be especially sure to test interactive features like forms, drop-down menus, pop-out menus, etc.
Test with a variety of input devices
Testing with a range of devices, including keyboard, mouse, special pointing devices which are supported by the user agent, will show if the event handlers can be used with the breadth of input devices supported by a user agent.
Guidelines for Web Accessibility - Priority 2- 2.1 Ensure that images have sufficient contrast for people with colour deficient vision
- 2.2 Avoid causing content to blink
- 2.3 Avoid movement in content
- 2.4 Ensure that dynamic content is accessible or provide an alternative presentation or page
- 2.5 Use style sheets to control layout and presentation
- 2.6 Use relative rather than absolute units
- 2.7 Use header elements to convey structure
- 2.8 Break up large blocks of information where appropriate
- 2.9 Ensure that information laid out using tables make sense when linearised, or provide an alternative equivalent
- 2.10 Do not use structural mark-up to format information laid out using tables
- 2.11 Describe the purpose of frames and how they relate to each other if it is not obvious by their titles alone
- 2.12 Clearly identify the target of each link
- 2.13 Provide information about pages and sites in metadata
- 2.14 Provide information about the general layout of a site
- 2.15 Use navigation mechanisms consistently
- 2.16 Associate labels explicitly with their controls
- 2.17 Properly position the labels of form controls
- 2.18 Ensure that user interfaces are device-independent
- 2.19 Use logical event handlers in scripts
- 2.20 Use input device-independent event handlers in scripts and applets
- 2.21 Ensure that scripts and applets are accessible
- 2.22 When an appropriate markup language exists, use markup rather than images to convey information
- 2.23 Create documents that validate to published formal grammars
- 2.24 Mark up lists and list items using the proper HTML tags
- 2.25 Use quotation mark-up for quotations, but not for formatting
- 2.26 Where possible, use appropriate W3C technologies of the latest supported versions
- 2.27 Avoid deprecated features of W3C technologies
- 2.28 Do not periodically auto-refresh pages
- 2.29 Do not use mark-up to redirect pages automatically
- 2.30 Do not generate pop-ups or other windows and do not change the current window without informing the user
