[contents]
Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
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 Working Draft). It includes techniques, code examples, and references to help authors satisfy each success criterion. The techniques in this document are specific to Hypertext Markup Language content [HTML4], [XHTML1] although some techniques contain Cascading Style Sheet solutions [CSS1]. Deprecated examples illustrate techniques that content developers should not use. The techniques listed in this document are suggestions on how to conform to WCAG 2.0. However, they may not be the only way to satisfy each success criterion.
Note: WCAG 2.0 is a Working Draft and the cross-references between success criteria and techniques are not fully established.
This document will be part of a series of documents published by the W3C Web Accessibility Initiative (WAI) to support WCAG 2.0.
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 prepared by the Web Content Accessibility Guidelines Working Group (WCAG WG) to show how HTML 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. This Working Draft in no way supersedes HTML Techniques for WCAG 1.0 published as a W3C Note September 2000. 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 "Issue tracking for WCAG 2.0 Techniques for HTML/XHTML" for a list of open issues related to this Working Draft. The History of Changes to HTML Techniques for WCAG 2.0 Working Drafts is also available.
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 Scripting Techniques for Web Content Accessibility Guidelines 2.0 (WCAG 2.0). This document describes techniques for authoring accessible ECMAScript-based scripts. ECMAScript is defined by the ECMA-262 specification.
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.
Note: Techniques in this document are known to contain errors. Recommendations 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.
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.
Editor's Note: This is being discussed in the WG presently.
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 Additionally, document.write() and innerHTML() can render content invalid after the fact, which presents problems for those assistive technologies that do support script.
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>";
}
One way to work around this limitation is to use the div element and the display property in CSS.
@@
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.
@@ tabindex? onblur/onfocus events?
@@
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.
<p><a href="menu.php" onactivate="checkForCookie()">main menu</a></p>