[contents]
Copyright © 2005 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use rules apply.
Editorial Note: The structure and presentation of the techniques documents will likely change as the WCAG WG determines the relationships between Guidelines, Techniques, and testing documents.
This document provides information to Web content developers who wish to satisfy the success criteria of "Web Content Accessibility Guidelines 2.0" [WCAG20] (currently a W3C Working Draft). The techniques in this document are specific to ECMAScript although some techniques contain Cascading Style Sheet [CSS1] and Hypertext Markup Language content [HTML4], [XHTML1] solutions. Use of the illustrative techniques provided in this document may make it more likely for Web content to demonstrate conformance to WCAG 2.0 success criteria (by passing the relevant tests in the WCAG 2.0 test suite - to be developed) than if these illustrative techniques are not used.
There may be other techniques besides those provided in this document that may be used to demonstrate conformance to WCAG 2.0; in that case, it is encouraged to submit those techniques to the WCAG WG for consideration for inclusion in this document, so that the set of techniques maintained by the WCAG WG is as comprehensive as possible. Deprecated examples illustrate techniques that the Working Group no longer recommends, but may be applicable in some cases.
Note: WCAG 2.0 is a Working Draft and the cross-references between success criteria and techniques are not fully established.
This document is part of a series of documents published by the W3C Web Accessibility Initiative (WAI) to support WCAG 2.0.
Editorial Note: As work on the technology-specific techniques documents and checklists progresses, we expect to clearly distinguish between techniques required for conformance versus those that are optional. That distinction is not made in this Working Draft. The issue is captured as Issue #772 -"How do we make it clear that there are some techniques that are sufficient and some that are optional?"
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document is the first public Working Draft prepared by the Web Content Accessibility Guidelines Working Group (WCAG WG) to show how Client-side Scripting Techniques for WCAG 2.0 might read. This draft is not yet based on consensus of the WCAG Working Group nor has it gone through W3C process. The WCAG WG intends to publish this as a Working Group Note at the same time or soon after WCAG 2.0 becomes a Recommendation.
Please refer to "Client Side Scripting Techniques Issues" for a list of open issues related to this Working Draft.for a list of open issues related to this Working Draft.
The Working Group welcomes comments on this document at public-comments-wcag20@w3.org. The archives for this list are publicly available.
This document has been produced as part of the W3C Web Accessibility Initiative (WAI). The goals of the WCAG WG are discussed in the Working Group charter. The WCAG WG is part of the WAI Technical Activity.
This is the Client-side Scripting Techniques for Web Content Accessibility Guidelines 2.0 [WCAG20] This document describes techniques for authoring accessible ECMAScript-based scripts. ECMAScript is defined by the ECMA-262 specification [ECMA262].
This document is intended to help authors of Web content who wish to claim conformance to WCAG 2.0. While the techniques in this document should increase overall accessibility of Web resources, they are not a comprehensive resource for script accessibility.
As discussed in Baseline Technologies Assumption WCAG 2.0 may depend on the User Agent Accessibility Guidelines 1.0 [UAAG10] to determine the standard for browsers and media players in terms of their direct accessibility and the formats that they support. Since UAAG 1.0 provides guidance on browser integration of scripting languages, if conformance to UAAG 1.0 is adopted as a baseline assumption, we can assume that script can be built in a manner that is accessible using conforming browsers. This is a different approach from WCAG 1.0 [WCAG10] Checkpoint 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."
With this in mind, it is important to remember that certain common scripting practices are inaccessible, or less accessible than others. For example, UAAG 1.0 specifies programmatic access to the Document Object Model (DOM), including notification of updates. Therefore, the Javascript document.write() method would not be any more accessible, since it doesn't interact with the DOM; the createElement method, and other DOM-related elements, are a more accessible solution.
In addition, authors should consider whether they genuinely need to use script in certain situations, or whether they can augment an HTML-based solution with script so that users with script turned off may still use the document. It is always important to adopt the least-restrictive set of technologies possible when authoring Web content. Or, as Postel's Law suggests: "Be liberal in what you accept, and conservative in what you send."
Note: Techniques in this document are known to contain errors, and will be rendered obsolete by future drafts. The purpose of this document is to receive feedback about the content of the techniques to ensure that future drafts are more accurate and useful. These techniques should not be implemented by people attempting to attain WCAG conformance at this time.
The resolution of the Baseline Technologies Assumption will determine the purpose and contents of this document. In particular, we need to answer the question, "Are functional alternatives required for content that contains scripting?" In other words, will WCAG 2.0 deprecate the alternative functionality requirement of WCAG 1.0 Checkpoint 6.3? This document is being published at this time to solicit review and discussion of these questions.
User agent support information is not included in this draft. In future drafts, the WCAG WG intends to provide this information to help authors decide which techniques to implement. Providing this information requires extensive user agent and assistive technology testing. The WCAG WG welcomes submissions of test result information that demonstrates user agent or assistive technology support (or lack of support) of existing techniques. Submissions of additional techniques are also welcome.
As work on the technology-specific checklists progresses, we expect to clearly distinguish between techniques required for conformance versus those that are optional. That distinction is not made in this Working Draft. The issue is captured as Issue #772 -"How do we make it clear that there are some techniques that are sufficient and some that are optional?"
Editorial Note: The WCAG WG anticipates that a separate techniques document will focus on metadata, semantic web issues, and RDF and will be referenced from this section.
This technique relates to the following sections of the guidelines:
Avoid javascript: URIs for form actions.
Setting the action attribute in a form to a javascript: URI causes non-script-capable browsers to fail silently.
This example code shows a problematic use of the javascript: URI:
<form action="javascript:submitmyform()"> ... </form>
Another common error is to point the form's action to "#" (the top of the current document), while using the onsubmit event. This causes users of non-script-capable browsers to become confused, as their repeated activation of the submit button does nothing.
<form action="#" onsubmit="submitmyform()"> ... </form>
The correct method for firing an ECMAScript function when a form is submitted is to use the onsubmit event.
The checkFormFields() function would return true if there are form errors, stopping the submission of the form:
<form action="submit.php" onsubmit="return checkFormFields();"> ... </form>
This technique relates to the following sections of the guidelines:
Avoid using images with onclick="form.submit()" as submit buttons.
A submit button is a submit button, and an image is an image. There is no need to mix the two. However, it is very common to see the following code, which leaves users of screen readers and people who can't use a mouse completely unable to submit their form:
<form> <img src="submit.gif" alt="Submit this form" onclick="submitmyform()"> </form>
The example below shows how to create an image-based submit button that is compatible with assistive technology:
<form> <input type="image" name="submit" src="submit.gif" alt="Submit this form"> </form>
This technique relates to the following sections of the guidelines:
Avoid javascript: URIs. Attach events using DOM event attributes.
The javascript: URI space should not be used. All ECMAScript should be designed to degrade gracefully when script is not supported, and javascript: URIs necessarily break that graceful degradation.
Editorial Note: This is being discussed in the WG presently. One issue is whether, if JavaScript is assumed to exist in the client, it is necessary to restrict javascript: URIs. On the other hand, the javascript: namespace has referentiality problems, and in many cases, users can enjoy backward-compatibility without any undue burden on the author. (See bug 1073 for more detail.)
Code such as the example below locks many users out of important portions of the site:
<a href="javascript:window.open('register.php')">click here</a> to register.
It is better in general to use the DOM events (onactivate, onclick, onkeypress, etc.) to call script functions, but leave a real http: URI in the link for non-script-capable browsers. In rare cases, it may be necessary to create a second page that duplicates the functionality of the page called by the script, but most of the time it is sufficient to point users to the same target page that is called by the script.
<a href="register.php" target="registerwindow"
onclick="window.open('',this.target);">register here</a>
This technique relates to the following sections of the guidelines:
Avoid document.write() and innerHTML().
Assistive technologies such as screen readers rely on the Document Object Model (DOM) to interpret the semantics in HTML for a different modality. Given this, the document.write() and innerHTML() methods can render content invalid (and inaccessible via DOM) after the fact.
This deprecated example shows a script that inserts a header, a paragraph (which is unterminated, and thus invalid), and a list (again, invalid) into a given document.
function fillContent() {
document.write("<h1>Welcome to my site</h1>");
document.write("<p>Lorem ipsum dolor sit amet");
document.menu.innerHTML = "<ul><li><a href="foo.html">foo</a>";
}
The following code sample does the same as the example above, but produces valid code which appears in the HTML document's DOM tree:
function fillContent() {
// parentelem is a specified element in the DOM
var header = document.createElement("h1");
header.insertText("Welcome to my site");
var para = document.createElement("p");
para.insertText("Lorem ipsum dolor sit amet");
var list = document.createElement("ul");
itemone = document.createElement("li");
itemonelink = document.createElement("a");
itemonelink.setAttribute("href","foo.html");
itemonelink.insertText("foo");
list.appendChild(itemone);
parentelem.appendChild(header);
parentelem.appendChild(para);
parentelem.appendChild(list);
}
Editorial Note: Two issues have been raised with this example what happens to XSL on server-side and how does this effect XPointers (and RDF-based accessibility).
This technique relates to the following sections of the guidelines:
Avoid changing focus on the user.
This includes such things as creating new windows, which are covered elsewhere in the techniques documents. But it also includes the focus() function in ECMAScript. Setting focus changes the cursor position in a screen reader, which is akin to moving the mouse without the author's position. Users are disoriented, and in certain cases, may not be able to get to certain parts of the document.
Editorial Note: tabindex? onblur/onfocus events?
Editorial Note: This technique is to be adapted in a later draft. We do not yet have a good code example for this, since it is related more to a chain reaction of sorts.
This technique relates to the following sections of the guidelines:
Avoid device-dependent events, or use both keyboard- and mouse-based functions.
<p><a href="menu.php" onclick="checkForCookie()" onkeypress="checkForCookie()">main menu</a></p>
This technique relates to the following sections of the guidelines:
Use the onactivate event in place of onclick.
With onactivate, keyboard users can trigger scripts by hitting enter on a target they've tabbed to, while mouse users can click on the same links.
Editorial Note: The technique below is to be adapted. While onactivate is invalid HTML, it is possible to attach an onactivate event to an element in the script block. However, this is a part of a broader strategy for techniques which will be explored in a later draft.
<p><a href="menu.php" onactivate="checkForCookie()">main menu</a></p>
This task wille describe an accessible method for interactive menus, also known as "DHTML menus".
Editorial Note: This technique is a placeholder. The editor will research methods for creating menus using script and CSS, have them tested against our requirements, and publish example code here.