Copyright © 2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document is a gateway to the documents describing techniques for authoring accessible content using different web technologies. It also includes information about satisfying the guidelines that is applicable in any technology. This document is intended to help authors of Web content who wish to claim conformance to "Web Content Accessibility Guidelines 2.0" ([WCAG20]). While the techniques in this document should help people author content that conforms to "Web Content Accessibility Guidelines 2.0", these techniques are neither guarantees of conformance nor the only way an author might produce conforming content.
Note: This document contains a number of examples that illustrate accessible solutions but also deprecated examples that illustrate what content developers should not do. The deprecated examples are highlighted and readers should approach them with caution -- they are meant for illustrative purposes only.
This document is prepared by the Web Content Accessibility Guidelines Working Group (WCAG WG) to show the way a Gateway Document for 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 content of this draft has not changed significantly since the September 2000 draft of Core Techniques for WCAG 1.0.
Please refer to "Issue tracking for WCAG 2.0 Core Techniques" for a list of open issues related to this Working Draft.
This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current W3C Recommendations and other technical documents is available.
The Working Group welcomes comments on this document at w3c-wai-gl@w3.org. The archives for this list are publicly available.
Patent disclosures relevant to this specification may be found on the WCAG Working Group's patent disclosure page in conformance with W3C policy.
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.
Editorial Note: Include reference to NFB document discussing alt descriptions.
Text is considered accessible to almost all users since it may be handled by screen readers, non-visual browsers, and braille readers. It may be displayed visually, magnified, synchronized with a video to create a caption, etc. As you design a document containing non-textual information (images, applets, sounds, multimedia presentations, etc.), supplement that information with textual equivalents wherever possible.
When a text equivalent is presented to the user, it fulfills essentially the same function (to the extent possible) as the original content. For simple content, a text equivalent may need only describe the function or purpose of content. For complex content (charts, graphs, etc.), the text equivalent may be longer and include descriptive information.
Text equivalents must be provided for logos, photos, submit buttons, applets, bullets in lists, ASCII art, and all of the links within an image map as well as invisible images used to lay out a page.
A good test to determine if a text equivalent is useful is to imagine reading the document aloud over the telephone. What would you say upon encountering this image to make the page comprehensible to the listener?
Audio InformationAudio presentations must be accompanied by text transcripts, textual equivalents of audio events. When these transcripts are presented synchronously with a video presentation they are called captions and are used by people who cannot hear the audio track of the video material.
Some media formats (e.g., QuickTime 3.0 and SMIL) allow captions and video descriptions to be added to the multimedia clip. SAMI allows captions to be added. The following example demonstrates that captions should include speech as well as other sounds in the environment that help viewers understand what is going on.
Captions for a scene from "E.T." The phone rings three times, then is answered.
[phone rings] [ring] [ring] "Hello?"
Until the format you are using supports alternative tracks, two versions of the movie could be made available, one with captions and audio descriptions, and one without. Some technologies, such as SMIL and SAMI, allow separate audio/visual files to be combined with text files via a synchronization file to create captioned audio and movies.
Some technologies also allow the user to choose from multiple sets of captions to match their reading skills. For more information see the SMIL 1.0 ([SMIL]) specification.
Editorial Note: reference to SMIL techniques?
Equivalents for sounds can be provided in the form of a text phrase on the page that links to a text transcript or description of the sound file. The link to the transcript should appear in a highly visible location such as at the top of the page. However, if a script is automatically loading a sound, it should also be able to automatically load a visual indication that the sound is currently being played and provide a description or transcript of the sound.
Note. Some controversy surrounds this technique because the browser should load the visual form of the information instead of the auditory form if the user preferences are set to do so. However, strategies must also work with today's browsers.
For more information, please refer to [NCAM].
Editorial Note: reference to Joe Clark's work?
Visual information and motionAudio descriptions of the visual track provide narration of the key visual elements without interfering with the audio or dialogue of a movie. Key visual elements include actions, settings, body language, graphics, and displayed text. Audio descriptions are used primarily by people who are blind to follow the action and other non-audio information in video material.
Here's an example of a collated text transcript of a clip from "The Lion King" (available at [DVS]). Note that the Describer is providing the audio description of the video track and that the description has been integrated into the transcript.
Simba: Yeah! Describer: Simba races outside, followed by his parents. Sarabi smiles and nudges Simba gently toward his father. The two sit side-by-side, watching the golden sunrise. Mufasa: Look Simba, everything the light touches is our kingdom. Simba: Wow.
Note. If there is no important visual information, for example, an animated talking head that describes (through prerecorded speech) how to use the site, then an audio description is not necessary.
For movies, provide audio descriptions that are synchronized with the original audio. Refer to the section on audio information for more information about multimedia formats.
Collated text transcriptsCollated text transcripts allow access by people with both visual and hearing disabilities. They also provide everyone with the ability to index and search for information contained in audio/visual materials.
Collated text transcripts include spoken dialogue as well as any other significant sounds including on-screen and off-screen sounds, music, laughter, applause, etc. In other words, all of the text that appears in captions as well as all of the descriptions provided in the audio description.
When designing a document or series of documents, content developers should strive first to identify the desired structure for their documents before thinking about how the documents will be presented to the user. Distinguishing the structure of a document from how the content is presented offers a number of advantages, including improved accessibility, manageability, and portability.
Identifying what is structure and what is presentation may be challenging at times. For instance, many content developers consider that a horizontal line communicates a structural division. This may be true for sighted users, but to unsighted users or users without graphical browsers, a horizontal line may have next to no meaning. For example, in HTML content developers should use the HTML 4.01 [HTML4] heading elements (H1-H6) to identify new sections. These may be complemented by visual or other cues such as horizontal rules, but should not be replaced by them.
Editorial Note: This paragraph is HTML-specific. Need broader range of examples, or more generic explanation.
The inverse holds as well: content developers should not use structural elements to achieve presentation effects. For instance in HTML, even though the BLOCKQUOTE element may cause indented text in some browsers, it is designed to identify a quotation, not create a presentation side-effect. BLOCKQUOTE elements used for indentation confuse users and search robots alike, who expect the element to be used to mark up block quotations.
Editorial Note: Will this example make any sense to someone who doesn't know HTML?
The separation of presentation from structure in XML documents is inherent. As Norman Walsh states in "A Guide to XML" [WALSH], "HTML browsers are largely hardcoded. A first level heading appears the way it does because the browser recognizes the H1 tag. Again, since XML documents have no fixed tag set, this approach will not work. The presentation of an XML document is dependent on a stylesheet."
To determine if content is structural or presentational, create an outline of your document. Each point in the hierarchy denotes a structural change. Use structural markup to mark these changes and presentational markup to make them more apparent visually and aurally. Notice that horizontal rules will not appear in this outline and therefore are not structural, but presentational. Note. This quicktest addresses chapter, section, and paragraph structure. To determine structure within phrases, look for abbreviations, changes in natural language, definitions, and list items.
Not every user has a graphic environment with a mouse or other pointing device. Some users rely on keyboard, alternative keyboard or voice input to navigate links, activate form controls, etc. Content developers must ensure that users may interact with a page with devices other than a pointing device. A page designed for keyboard access (in addition to mouse access) will generally be accessible to users with other input devices. What's more, designing a page for keyboard access will usually improve its overall design as well.
Keyboard access to links and form controls may be specified in a few ways:
Provide text equivalents for client-side image map areas, or provide redundant text links for server-side image maps. Refer to the image map section for examples.
Editorial Note: Should be moved to HTML techniques; also update reference from WCAG1
Provide keyboard shortcuts so that users may combine keystrokes to navigate links or form controls on a page. Note. Keyboard shortcuts -- notably the key used to activate the shortcut -- may be handled differently by different operating systems. On Windows machines, the "alt" and "ctrl" key are most commonly used while on a Macintosh, it is the apple or "clover leaf" key. Refer to the Keyboard access for links and Keyboard Access to Forms sections for examples.
Editorial Note: Update references to WCAG10. Should we even be including pointers to technology specific items in our gateway discussion?
Tabbing order describes a (logical) order for navigating from link to link or form control to form control (usually by pressing the "tab" key, hence the name). Refer to the Keyboard Access to Forms section for examples.
Editorial Note: Update references to WCAG10. Should we even be including pointers to technology specific items in our gateway discussion?
Editorial Note: Other ideas for this section: strategies to navigate into long lists, jump over chunks into middle of chunks; how structure relates to navigation; workflow; relation to UAAG; menus and scripting, keyboard access
Content developers sometimes create pages that refresh or change without the user requesting the refresh. This automatic refresh can be very disorienting to some users. Instead, in order of preference, authors should:
Configure the server to use the appropriate HTTP status code (301). Using HTTP headers is preferable because it reduces Internet traffic and download times, it may be applied to non-HTML documents, and it may be used by agents who requested only a HEAD request (e.g., link checkers). Also, status codes of the 30x type provide information such as "moved permanently" or "moved temporarily" that cannot be given with META refresh.
Replace the page that would be redirected with a static page containing a normal link to the new page.
A flickering or flashing screen may cause seizures in users with photosensitive epilepsy and content developers should thus avoid causing the screen to flicker. Seizures can be triggered by flickering or flashing in the 4 to 59 flashes per second (Hertz) range with a peak sensitivity at 20 flashes per second as well as quick changes from dark to light (like strobe lights).
Editorial Note: Need to discuss difficulties in testing. Include references.
The following sections discuss techniques for helping comprehension of a page or site.
Writing styleThe following writing style suggestions should help make the content of your site easier to read for everyone, especially people with reading and/or cognitive disabilities. Several guides (including [HACKER]) discuss these and other writing style issues in more detail.
Strive for clear and accurate headings and link descriptions. This includes using link phrases that are terse and that make sense when read out of context or as part of a series of links (Some users browse by jumping from link to link and listening only to link text.) Use informative headings so that users can scan a page quickly for information rather than reading it in detail.
State the topic of the sentence or paragraph at the beginning of the sentence or paragraph (this is called "front-loading"). This will help both people who are skimming visually, but also people who use speech synthesizers. "Skimming" with speech currently means that the user jumps from heading to heading, or paragraph to paragraph and listens to just enough words to determine whether the current chunk of information (heading, paragraph, link, etc.) interests them. If the main idea of the paragraph is in the middle or at the end, speech users may have to listen to most of the document before finding what they want. Depending on what the user is looking for and how much they know about the topic, search features may also help users locate content more quickly.
Limit each paragraph to one main idea.
Avoid slang, jargon, and specialized meanings of familiar words, unless defined within your document.
Favor words that are commonly used. For example, use "begin" rather than "commence" or use "try" rather than "endeavor."
Use active rather than passive verbs.
Avoid complex sentence structures.
To help determine whether your document is easy to read, consider using the Gunning-Fog reading measure (described in[SPOOL] with examples and the algorithm online at [TECHHEAD]). This algorithm generally produces a lower score when content is easier to read. As example results, the Bible, Shakespeare, Mark Twain, and TV Guide all have Fog indexes of about 6. Time, Newsweek, and the Wall St. Journal an average Fog index of about 11.
Editorial Note: This section is heavily skewed towards techniques for English; need to expand to other languages.
Illustrating TextFor people who do not read well or not at all, multimedia (non-text) equivalents may help facilitate comprehension. Beware that multimedia presentations do not always make text easier to understand. Sometimes, multimedia presentations may make it more confusing.
Examples of multimedia that supplement text:
A chart of complex data, such as sales figures of a business for the past fiscal year.
A translation of the text into a Sign Language movie clip. Sign Language is a very different language than spoken languages. For example, some people who may communicate via American Sign Language may not be able to read American English.
Pre-recorded audio of music, spoken language, or sound effects may also help non-readers who can perceive audio presentations. Although text may be generated as speech through speech synthesis, changes in a recorded speaker's voice can convey information that is lost through synthesis.
A consistent style of presentation on each page allows users to locate navigation mechanisms more easily but also to skip navigation mechanisms more easily to find important content. This helps people with learning and reading disabilities but also makes navigation easier for all users. Predictability will increase the likelihood that people will find information at your site, or avoid it when they so desire.
Examples of structures that may appear at the same place between pages:
navigation bars
the primary content of a page
advertising
A navigation mechanism creates a set of paths a user may take through your site. Providing navigation bars, site maps, and search features all increase the likelihood that a user will reach the information they seek at your site. If your site is highly visual in nature, the structure might be harder to navigate if the user can't form a mental map of where they are going or where they have been. To help them, content developers should describe any navigation mechanisms. It is crucial that the descriptions and site guides be accessible since people who are lost at your site will rely heavily on them.
When providing search functionality, content developers should offer search mechanisms that satisfy varying skill levels and preferences. Most search facilities require the user to enter keywords for search terms. Users with spelling disabilities and users unfamiliar with the language of your site will have a difficult time finding what they need if the search requires perfect spelling. Search engines might include a spell checker, offer "best guess" alternatives, query-by-example searches, similarity searches, etc.
Editorial Note: This section seems to be discussing benefits more than techniques.
Editorial Note: This discussion needs a lot of work. We need an explicit reference to UAAG and its test suites. Need to talk about what to look for as someone reads the techniques, e.g., browser and AT support.
Support: Note. At the time of this writing, not all user agents support some of the HTML 4.01 [HTML4] attributes and elements that may significantly increase accessibility of Web pages.Please refer to the W3C Web site ([WAI-UA-SUPPORT]) for information about browser and other user agent support of accessibility features.
In general, please note that HTML user agents ignore attributes they don't support and they render the content of unsupported elements.
Brief overview of current W3C technologies:
MathML for mathematical equations
HTML, XHTML, XML for structured documents
RDF for meta data
SMIL to create multimedia presentations
CSS and XSL to define style sheets
XSLT to create style transformations
PNG for graphics (although some are best expressed in JPG, a non-w3c spec)
Editorial Note: From WCAG1 document: Are there others that we need to discuss? WebCGM? Do we want to recommend HTML over XHTML? what about CSS1 and CSS2? What about non-W3C specifications like PDF, Flash, etc.
Editorial Note: Link to Java, PDF, Flash techs?
Although it is possible to make most content accessible, it may happen that all or part of a page remains inaccessible. Additional techniques for creating accessible alternatives include:
Allow users to navigate to a separate page that is accessible, contains the same information as the inaccessible page, and is maintained with the same frequency as the inaccessible page.
Instead of static alternative pages, set up server-side scripts that generate accessible versions of a page on demand.
Editorial Note: Should move to ServerSide Techniques
Refer to the examples for Frames and Scripts.
Editorial Note: Should move to HTML techniques?
Provide a phone number, fax number, e-mail, or postal address where information is available and accessible, preferably 24 hours a day
Here are two techniques for linking to an accessible alternative page:
Provide links at the top of both the main and alternative pages to allow a user to move back and forth between them. For example, at the top of a graphical page include a link to the text-only page, and at the top of a text-only page include a link to the associated graphical page. Ensure that these links are one of the first that users will tab to by placing them at the top of the page, before other links.
Use meta information to designate alternative documents. Browsers should load the alternative page automatically based on the user's browser type and preferences
Some elements import objects (e.g., applets or multimedia players) whose interfaces cannot be controlled through the markup language. In such cases, content developers should provide alternative equivalents with accessible interfaces if the imported objects themselves do not provide accessible interfaces.
There are a variety of strategies to allow users to negotiate to select the appropriate content:
Include links to other versions of content, such as translations. For example, the link "Refer to the French version of this document" links to the French version.
Indicate content type or language through markup (e.g., in HTML use "type" and "hreflang").
Use content negotiation to serve content per the client request. For example, serve the French version of a document to clients requesting French.
Editorial Note: It isn't clear where the following info should go
Bundled documents can facilitate reading offline. To create a coherent package:
Use metadata to describe the relationships between components of the package (refer to link metadata for HTML).
Use archiving tools such as zip, tar and gzip, and StuffIt to create the package.
Editorial Note: It isn't clear where the following info should go, or even whether it is still all good advice!
Content developers must consider backward compatibility when designing Web pages or sites since:
Some user agents do not support some HTML features,
People may use older browsers or video players,
Compatibility problems may arise between software
Therefore, when designing for older technologies, consider these techniques:
Provide inline text equivalents. For example, include a description of the image immediately after the image.
Provide links to long text equivalents either in a different file or on the same page. These are called description links or "d-links". The link text should explain that the link designates a description. Where possible, it should also explain the nature of the description. However, content developers concerned about how the description link will affect the visual appearance of the page may use more discrete link text such as "[D]", which is recommended by NCAM (refer to [NCAM]). In this case, they should also provide more information about the link target so that users can distinguish links that share "[D]" as content (e.g., with the "title" attribute in HTML).
Editorial Note: It isn't clear where the following info should go, or whether it belongs in this document at all. Perhaps we should just refer to the EO Evaluation test suite, and /or Shawn Henry's paper.
This section discusses strategies and techniques for testing Web documents to determine accessibility issues that have been resolved and those that haven't. These tests should highlight major access issues, and are valuable in reducing a number of accessibility barriers. However, some of these testing scenarios only replicate conditions caused by a disability; they do not simulate the full experience a user with a disability might have. In real-life settings, your pages may be less usable than you expected. Thus, one of the strategies recommends that content developers observe people with different disabilities as they attempt to use a page or site.
If, after completing the following tests and adjusting your design accordingly, you find that a page is still not accessible, it is likely that you should create an alternative page that is accessible.
Note. Passing these tests does not guarantee conformance to the "Web Content Accessibility Guidelines 2.0".
Automatic validatorsA validator can verify the syntax of your pages (e.g., HTML, CSS, XML). Correct syntax will help eliminate a number of accessibility problems since software can process well-formed documents more easily. Also, some validators can warn you of some accessibility problems based on syntax alone (e.g., a document is missing an attribute or property that is important to accessibility). Note, however, that correct syntax does not guarantee that a document will be accessible. For instance, you may provide a text equivalent for an image according to the language's specification, but the text may be inaccurate or insufficient. Some validators will therefore ask you questions and step you through more subjective parts of the analysis. Some examples of automatic validators include:
Repair toolsValidators usually report what issues to solve and often give examples of how to solve them. They do not usually help an author walk through each problem and help the author modify the document interactively. The WAI Evaluation and Repair Working Group ([WAI-ER]) is working to develop a suite of tools that will help authors not only identify issues but solve them interactively.
User scenariosKeep in mind that most user agents (browsers) and operating systems allow users to configure settings that change the way software looks, sounds, and behaves. With the variety of user agents, different users will have very different experiences with the Web. Therefore:
Test your pages with a text-only browser such as Lynx ([LYNX]) or a Lynx emulator such as Lynx Viewer ([LYNXVIEW]) or Lynx-me ([LYNXME]).
Use multiple graphic browsers, with:
sounds and images loaded,
images not loaded,
sounds not loaded,
no mouse,
frames, scripts, style sheets, and applets not loaded.
Use several browsers, old and new. Note. Some operating systems or browsers do not allow multiple installations of the browser on the same machine. It may also be difficult to locate older browser software.
Use other tools such as a self-voicing browser (e.g., [PWWEBSPEAK] and [HOMEPAGEREADER]), a screen reader (e.g., [JAWS] and [WINVISION]), magnification software, a small display, an onscreen keyboard, an alternative keyboard, etc. Note. If a Web site is usable with one of these products it does not ensure that the site will be usable by other products. For a more detailed list of assistive technologies used to access the Web refer to ([ALTBROWSERS]).
Spell and grammar checksA person reading a page with a speech synthesizer may not be able to decipher the synthesizer's best guess for a word with a spelling error. Grammar checkers will help to ensure that the textual content of your page is correct. This will help readers for whom your document is not written in their native tongue, or people who are just learning the language of the document. Thus, you will help increase the comprehension of your page.