Developer Checklist

The following checklists are intended to guide developers on the implementation of success criteria for JavaScript, and are broadly grouped by the kind of functionality that each requirement relates to:

  • General Principles
  • Interactive Content (i.e., custom widgets, image viewers, maps, calendars etc.)
  • Menus and Navigation
  • Form Validation
  • Audio and Video

The checklists should be used during the development phase to ensure WCAG 2.0 compliance of all JavaScript on the site, and should form part of the unit testing phase undergone by developers when updating or creating new content or functionality.

Level A

General Principles

JS_G_A1: All non-text content has an equivalent text alternative

Details
Visually-dynamic information (such as a progress meter) should have a text equivalent
Correct example(s)

JS_G_A2: All non-text content has an equivalent text alternative

Details
Functionality that can’t be made accessible must have a long description that provides the same information
Correct example(s)

JS_G_A3:All non-text content has an equivalent text alternative

Details
Functionality that can’t be presented in text must be descriptively identified
Correct example(s)

JS_G_A4: All non-text content has an equivalent text alternative

Details
Functionality that relies on JavaScript should not be present when JavaScript is unavailable
Correct example(s)

JS_G_A5: Labels or instructions are provided when content requires user input

Details
Interactive content must have an associated label or short instructions about its behaviour
Correct example(s)

JS_G_A6: Information and structure can be programmatically determined

Details
Use functions of the DOM to add content to a page
Correct example(s)

JS_G_A7: Information and structure can be programmatically determined

Details
Do not use events to emulate the behaviour of links
Correct example(s)
<a href="page.html">
Incorrect example(s)
<span onclick="document.location='page.html'">

JS_G_A8: Blocks of repeating content can be bypassed

Details
Use an expandable/collapsible menu to bypass blocks of content
Correct example(s)

Interactive Content

JS_C_A1: All functionality is operable through a keyboard interface

Details
Interactive content should be accessible to the keyboard, using common keystrokes like ‘Tab’, ‘Enter’ and Arrow Keys
Correct example(s)

JS_C_A2: Use the click event of links and buttons as an activation event

Details
Use the click event of links and buttons as an activation event
Correct example(s) Incorrect example(s)
<input type="button" value="Compute Monthly Pay” onkeypress="compute()">

JS_C_A3: All functionality is operable through a keyboard interface

Details
Mouse actions must be paired with equivalent keyboard actions
Correct example(s)

JS_C_A4: All functionality is operable through a keyboard interface

Details
Do not use events to restrict keyboard access or remove focus indication
Incorrect example(s)
onfocus="this.blur()"

JS_C_A5: Timed activity can be controlled

Details
Warn the user when a time-limit is about to expire, and provide a mechanism for extending it
Correct example(s)

JS_C_A6: Timed activity can be controlled

Details
Use scripting to scroll content and provide a mechanism to pause it
Correct example(s)

JS_C_A7: Timed activity can be controlled

Details
Use scripting to create an alternative, static version of scrolling content
Correct example(s)

JS_C_A8: Timed activity can be controlled

Details
Use scripting to create a blinking animation that stops in 5 seconds
Correct example(s)

JS_C_A9: Maintain a logical focus order for interactive components

Details
Insert dynamic content into the DOM immediately following its trigger element
Correct example(s)

JS_C_A10: Maintain a logical focus order for interactive components

Details
Create custom dialogs in a device independent way
Correct example(s)

JS_C_A11: Maintain a logical focus order for interactive components

Details
Use scripting to re-order content in the DOM
Correct example(s)

JS_C_A12: Changes of context are only initiated by user request or with user control

Details
Use progressive enhancement to open custom dialogs on user request
Correct example(s)

Menus and Navigation

JS_N_A1: All functionality is operable through a keyboard interface

Details
Dynamic menus should be fully accessible to the keyboard, using ‘Tab’ and Arrow Keys
Correct example(s)

JS_N_A2: Changes of context are only initiated by user request or with user control

Details
Use an actuation event, rather than focus or load event, to programmatically open links or trigger popup windows
Correct example(s)

JS_N_A3: Changes of context are only initiated by user request or with user control

Details
Use progressive enhancement to open windows on user request
Correct example(s)

JS_N_A4: Changes of context are only initiated by user request or with user control

Details
Do not use the change event of a SELECT element for navigation
Correct example(s)

JS_N_A5: Changes of context are only initiated by user request or with user control

Details
Do not automatically redirect the page using JavaScript
Correct example(s)

JS_N_A6: Changes of context are only initiated by user request or with user control

Details
Do not automatically refresh the page without user confirmation or control
Correct example(s)

Form Validation

JS_F_A1 If an input error is detected, the field should be identified and the error described in text

Details
Form validation should be triggered by submission, rather than individual field events
Correct example(s)

JS_F_A2: Form submission should be bound to the form’s submit event, not to the submit button’s click event

Details
Form submission should be bound to the form’s submit event, not to the submit button’s click event
Correct example(s)
<form action="/search" onsubmit="return validate(this)">
Incorrect example(s)
<input type="submit" onclick="return validate(this)">

JS_F_A3: If an input error is detected, the field should be identified and the error described in text

Details
Form validation should trigger an alert then set focus on the first invalid field
Correct example(s)

JS_F_A4: If an input error is detected, the field should be identified and the error described in text

Details
Validation error messages should be programmatically inserted directly after the field they relate to, using functions of the DOM
Correct example(s)

JS_F_A5: If an input error is detected, the field should be identified and the error described in text

Details
Do not force the focus to remain in invalid fields
Correct example(s)

Level AA

Form Validation

JS_F_AA1: If an input error is detected, and suggestions for corrections are known, these can be provided in text

Details
Where form fields require a specific format or range of values, contextual help-text can be programmatically inserted directly after the field it relates to, using functions of the DOM
Correct example(s)