web content accessibility guidelines 1.0

34 i n t e r a c t i o n s . . . j u l y + a u g u s t 2 0 0 1

© Joanna Szachowska/Images.com, Inc.

35

A b s t r a c tThese guidelines explain how to make Web contentaccessible to people with disabilities. The guidelinesare intended for all Web content developers (pageauthors and site designers) and for developers ofauthoring tools. The primary goal of these guidelinesis to promote accessibility. However, following themwill also make Web content more available to allusers, whatever user agent they are using (e.g., desk-top browser, voice browser, mobile phone, automo-bile-based personal computer, etc.) or constraints theymay be operating under (e.g., noisy surroundings,under- or over-illuminated rooms, in a hands-freeenvironment, etc.). Following these guidelines willalso help people find information on the Web morequickly. These guidelines do not discourage contentdevelopers from using images, video, etc., but ratherexplain how to make multimedia content more acces-sible to a wide audience.

This is a reference document for accessibility princi-ples and design ideas. Some of the strategies dis-cussed in this document address certain Webinternationalization and mobile access concerns.However, this document focuses on accessibility anddoes not fully address the related concerns of otherW3C Activities. Please consult the W3C Mobile AccessActivity home page and the W3C Internationalization

Activity home page for more information. This document is meant to be stable and therefore

does not provide specific information about browsersupport for different technologies as that informationchanges rapidly. Instead, the Web Accessibility Initia-tive (WAI) Web site provides such information (referto [WAI-UA-SUPPORT]).

This document includes an appendix that organizesall of the checkpoints by topic and priority. The check-points in the appendix link to their definitions in thecurrent document. The topics identified in theappendix include images, multimedia, tables, frames,forms, and scripts. The appendix is available as eithera tabular summary of checkpoints or as a simple list ofcheckpoints.

A separate document, entitled “Techniques forWeb Content Accessibility Guidelines 1.0” ([TECH-NIQUES]), explains how to implement the check-points defined in the current document. TheTechniques Document discusses each checkpoint inmore detail and provides examples using the Hyper-text Markup Language (HTML), Cascading StyleSheets (CSS), Synchronized Multimedia IntegrationLanguage (SMIL), and the Mathematical Markup Lan-guage (MathML). The Techniques Document alsoincludes techniques for document validation andtesting, and an index of HTML elements and

i n t e r a c t i o n s . . . j u l y + a u g u s t 2 0 0 1

Web ContentAccessibilityGuidelines 1.0E D I T O R S :

Wendy Chisholm, Trace R & D Center, University of Wisconsin—MadisonGregg Vanderheiden, Trace R & D Center, University of Wisconsin—MadisonIan Jacobs, W3C

address typical scenarios (similar to the fontstyle example) that may pose problems forusers with certain disabilities. For example,the first guideline explains how contentdevelopers can make images accessible. Someusers may not be able to see images, othersmay use text-based browsers that do not sup-port images, while others may have turned offsupport for images (e.g., due to a slow Inter-net connection). The guidelines do not sug-gest avoiding images as a way to improveaccessibility. Instead, they explain that pro-viding a text equivalent of the image willmake it accessible.

How does a text equivalent make the imageaccessible? Both words in “text equivalent” areimportant:

✱ Text content can be presented to theuser as synthesized speech, braille,and visually-displayed text. Each ofthese three mechanisms uses a differ-ent sense—ears for synthesizedspeech, tactile for braille, and eyes forvisually-displayed text—making theinformation accessible to groups rep-resenting a variety of sensory and oth-er disabilities.

✱ In order to be useful, the text mustconvey the same function or purpose asthe image. For example, consider a textequivalent for a photographic image ofthe Earth as seen from outer space. Ifthe purpose of the image is mostly thatof decoration, then the text “Photo-graph of the Earth as seen from outerspace” might fulfill the necessary func-tion. If the purpose of the photographis to illustrate specific informationabout world geography, then the textequivalent should convey that informa-tion. If the photograph has been

1. IntroductionFor those unfamiliar with accessibility issuespertaining to Web page design, consider thatmany users may be operating in contexts verydifferent from your own:

✱ They may not be able to see, hear,move, or may not be able to processsome types of information easily or at all.

✱ They may have difficulty reading orcomprehending text.

✱ They may not have or be able to use akeyboard or mouse.

✱ They may have a text-only screen, a small screen, or a slow Internet connection.

✱ They may not speak or understand flu-ently the language in which the docu-ment is written.

✱ They may be in a situation where theireyes, ears, or hands are busy or inter-fered with (e.g., driving to work, work-ing in a loud environment, etc.).

✱ They may have an early version of abrowser, a different browser entirely, avoice browser, or a different operatingsystem.

Content developers must consider these dif-ferent situations during page design. Whilethere are several situations to consider, eachaccessible design choice generally benefits sev-eral disability groups at once and the Web com-munity as a whole. For example, by using stylesheets to control font styles and eliminating theFONT element, HTML authors will havemore control over their pages, make thosepages more accessible to people with low vision,and by sharing the style sheets, will often short-en page download times for all users.

The guidelines discuss accessibility issuesand provide accessible design solutions. They


attributes (and which techniques use them).The Techniques Document has beendesigned to track changes in technologyand is expected to be updated more fre-quently than the current document. Note.Not all browsers or multimedia tools maysupport the features described in the guide-lines. In particular, new features of HTML

4.0 or CSS 1 or CSS 2 may not be supported.“Web Content Accessibility Guidelines

1.0” is part of a series of accessibility guide-lines published by the Web Accessibility Ini-tiative. The series also includes User AgentAccessibility Guidelines ([WAI-USERAGENT])and Authoring Tool Accessibility Guidelines([WAI-AUTOOLS]).

37i n t e r a c t i o n s . . . j u l y + a u g u s t 2 0 0 1

ly. Pages that transform gracefully remainaccessible despite any of the constraintsdescribed in the introduction, including phys-ical, sensory, and cognitive disabilities, workconstraints, and technological barriers. Hereare some keys to designing pages that trans-form gracefully:

✱ Separate structure from presentation(refer to the difference between con-tent, structure, and presentation).

✱ Provide text (including text equiva-lents). Text can be rendered in waysthat are available to almost all browsingdevices and accessible to almost allusers.

✱ Create documents that work even if the

user cannot see and/or hear. Provideinformation that serves the same pur-pose or function as audio or video inways suited to alternate sensory chan-nels as well. This does not mean creat-ing a prerecorded audio version of anentire site to make it accessible to userswho are blind. Users who are blind can

designed to tell the user to select theimage (e.g., by clicking on it) for infor-mation about the earth, equivalent textwould be “Information about theEarth.” Thus, if the text conveys thesame function or purpose for the userwith a disability as the image does forother users, then it can be considered atext equivalent.

Note that, in addition to benefitting userswith disabilities, text equivalents can help allusers find pages more quickly, since searchrobots can use the text when indexing the pages.

While Web content developers must pro-vide text equivalents for images and other mul-timedia content, it is the responsibility of useragents (e.g., browsers andassistive technologies such asscreen readers, braille dis-plays, etc.) to present theinformation to the user.

Non-text equivalents oftext (e.g., icons, pre-recordedspeech, or a video of a persontranslating the text into signlanguage) can make docu-ments accessible to peoplewho may have difficultyaccessing written text, includ-ing many individuals withcognitive disabilities, learningdisabilities, and deafness.Non-text equivalents of textcan also be helpful to non-readers. An auditory descrip-tion is an example of anon-text equivalent of visualinformation. An auditorydescription of a multimediapresentation’s visual trackbenefits people who cannotsee the visual information.

2. Themes of Accessible DesignThe guidelines address two general themes:ensuring graceful transformation, and mak-ing content understandable and navigable.

2.1 Ensuring Graceful TransformationBy following these guidelines, content devel-opers can create pages that transform graceful-

S t a t u s o f t h i s d o c u m e n tThis document has been reviewed by W3C Members and other interested

parties and has been endorsed by the Director as a W3C Recommenda-

tion. It is a stable document and may be used as reference material or

cited as a normative reference from another documents. W3C’s role in

making the Recommendation is to draw attention to the specification

and to promote its widespread deployment. This enhances the function-

ality and universality of the Web.

The English version of this specification is the only normative version.

However, for translations in other languages see

http://www.w3.org/WAI/GL/WAI-WEBCONTENT-TRANSLATIONS.

The list of known errors in this document is available at

http://www.w3.org/WAI/GL/WAI-WEBCONTENT-ERRATA. Please report

errors in this document to [email protected].

A list of current W3C Recommendations and other technical docu-

ments can be found at http://www.w3.org/TR.

This document has been produced as part of the W3C Web Accessibility

Initiative. The goal of the Web Content Guidelines Working Group is dis-

cussed in the Working Group charter.

The specifications may be found at: http://www.w3.org/TR/WCAG10/

COPYRIGHT © 1999 W3C (MIT, INRIA, KEIO), ALL RIGHTS RESERVED. W3C LIABILITY, TRADEMARK,DOCUMENT USE AND SOFTWARE LICENSING RULES APPLY.

and some groups of users who benefitfrom it.

✱ A list of checkpoint definitions. The checkpoint definitions in each guide-

line explain how the guideline applies in typi-cal content development scenarios. Eachcheckpoint definition includes:

✱ The checkpoint number. ✱ The statement of the checkpoint. ✱ The priority of the checkpoint. Priori-

ty 1 checkpoints are highlightedthrough the use of style sheets.

✱ Optional informative notes, clarifyingexamples, and cross references to relat-ed guidelines or checkpoints.

✱ A link to a section of the TechniquesDocument ([TECHNIQUES]) whereimplementations and examples of thecheckpoint are discussed.

Each checkpoint is intended to be specificenough so that someone reviewing a page orsite may verify that the checkpoint has beensatisfied.

3.1 Document conventionsThe following editorial conventions are usedthroughout this document:

✱ Element names are in uppercase letters. ✱ Attribute names are quoted in lower-

case letters. ✱ Links to definitions are highlighted

through the use of style sheets.

4. PrioritiesEach checkpoint has a priority level assignedby the Working Group based on the check-point’s impact on accessibility.

[Priority 1] A Web content developer must satisfy this

checkpoint. Otherwise, one or more groupswill find it impossible to access information inthe document. Satisfying this checkpoint is abasic requirement for some groups to be ableto use Web documents.

[Priority 2] A Web content developer should satisfy

this checkpoint. Otherwise, one or moregroups will find it difficult to access informa-tion in the document. Satisfying this check-point will remove significant barriers toaccessing Web documents.

use screen reader technology to renderall text information in a page.

✱ Create documents that do not rely onone type of hardware. Pages should beusable by people without mice, withsmall screens, low resolution screens,black and white screens, no screens,with only voice or text output, etc.

The theme of graceful transformation isaddressed primarily by guidelines 1 to 11.

2.2 Making Content Understandable andNavigableContent developers should make contentunderstandable and navigable. This includesnot only making the language clear and sim-ple, but also providing understandable mecha-nisms for navigating within and betweenpages. Providing navigation tools and orienta-tion information in pages will maximize acces-sibility and usability. Not all users can makeuse of visual clues such as image maps, propor-tional scroll bars, side-by-side frames, orgraphics that guide sighted users of graphicaldesktop browsers. Users also lose contextualinformation when they can only view a por-tion of a page, either because they are accessingthe page one word at a time (speech synthesisor braille display), or one section at a time(small display, or a magnified display). With-out orientation information, users may not beable to understand very large tables, lists,menus, etc.

The theme of making content understand-able and navigable is addressed primarily inguidelines 12 to 14.

3. How the Guidelines are OrganizedThis document includes fourteen guidelines,or general principles of accessible design. Eachguideline includes:

✱ The guideline number. ✱ The statement of the guideline. ✱ Guideline navigation links. Three links

allow navigation to the next guideline(right arrow icon), the previous guide-line (left arrow icon), or the currentguideline’s position in the table of con-tents (up arrow icon).

✱ The rationale behind the guideline



Provide content that, when presented to the user,conveys essentially the same function or purposeas auditory or visual content. Although some people cannot use images,movies, sounds, applets, etc. directly, theymay still use pages that include equivalentinformation to the visual or auditory content.The equivalent information must serve thesame purpose as the visual or auditory con-tent. Thus, a text equivalent for an image ofan upward arrow that links to a table of con-tents could be “Go to table of contents.” Insome cases, an equivalent should also describethe appearance of visual content (e.g., forcomplex charts, billboards, or diagrams) orthe sound of auditory content (e.g., for audiosamples used in education).

This guideline emphasizes the importanceof providing text equivalents of non-text con-tent (images, pre-recorded audio, video). Thepower of text equivalents lies in their capacityto be rendered in ways that are accessible topeople from various disability groups using avariety of technologies. Text can be readilyoutput to speech synthesizers and braille dis-plays, and can be presented visually (in a vari-ety of sizes) on computer displays and paper.Synthesized speech is critical for individualswho are blind and for many people with thereading difficulties that often accompany cog-nitive disabilities, learning disabilities, anddeafness. Braille is essential for individualswho are both deaf and blind, as well as manyindividuals whose only sensory disability isblindness. Text displayed visually benefitsusers who are deaf as well as the majority ofWeb users.

Providing non-text equivalents (e.g., pic-tures, videos, and pre-recorded audio) of textis also beneficial to some users, especially non-readers or people who have difficulty reading.In movies or visual presentations, visual actionsuch as body language or other visual cuesmay not be accompanied by enough audioinformation to convey the same information.Unless verbal descriptions of this visual infor-mation are provided, people who cannot see(or look at) the visual content will not be ableto perceive it.

Checkpoints:1.1 Provide a text equivalent for every non-

[Priority 3] A Web content developer may address this

checkpoint. Otherwise, one or more groupswill find it somewhat difficult to access infor-mation in the document. Satisfying this check-point will improve access to Web documents.

Some checkpoints specify a priority levelthat may change under certain (indicated)conditions.

5. ConformanceThis section defines three levels of confor-mance to this document:

✱ Conformance Level “A”: all Priority 1checkpoints are satisfied;

✱ Conformance Level “Double-A”: all Pri-ority 1 and 2 checkpoints are satisfied;

✱ Conformance Level “Triple-A”: all Prior-ity 1, 2, and 3 checkpoints are satisfied;

Note. Conformance levels are spelled out intext so they may be understood when ren-dered to speech.

Claims of conformance to this documentmust use one of the following two forms.

Form 1: Specify:✱ The guidelines title: “Web Content

Accessibility Guidelines 1.0” ✱ The guidelines URI:

http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505

✱ The conformance level satisfied: “A,”“Double-A,” or “Triple-A.”

✱ The scope covered by the claim (e.g.,page, site, or defined portion of a site).

Example of Form 1:This page conforms to W3C’s “Web Con-

tent Accessibility Guidelines 1.0,” available athttp://www.w3.org/TR/1999/WAI-WEB-CONTENT-19990505, level Double-A. Form 2: Include, on each page claiming con-formance, one of three icons provided byW3C and link the icon to the appropriateW3C explanation of the claim. Informationabout the icons and how to insert them inpages is available at [WCAG-ICONS].

6. Web Content AccessibilityGuidelinesGuideline 1. Provide equivalentalternatives to auditory and visualcontent.


text element (e.g., via “alt,” “longdesc,” or inelement content). This includes: images,graphical representations of text (includingsymbols), image map regions, animations(e.g., animated GIFs), applets and program-matic objects, ascii art, frames, scripts, imagesused as list bullets, spacers, graphical buttons,sounds (played with or without user interac-tion), stand-alone audio files, audio tracks ofvideo, and video. [Priority 1]

For example, in HTML: ✱ Use “alt” for the IMG, INPUT, and

APPLET elements, or provide a textequivalent in the content of theOBJECT and APPLET elements.

✱ For complex content (e.g., a chart)where the “alt” text does not provide acomplete text equivalent, provide anadditional description using, for exam-ple, “longdesc” with IMG or FRAME,a link inside an OBJECT element, or adescription link.

✱ For image maps, either use the “alt”attribute with AREA, or use the MAPelement with A elements (and othertext) as content. Refer also to checkpoint 9.1 andcheckpoint 13.10. Techniques for checkpoint 1.1

1.2 Provide redundant text links for eachactive region of a server-side image map. [Pri-ority 1]

Refer also to checkpoint 1.5 andcheckpoint 9.1. Techniques for checkpoint 1.2

1.3 Until user agents can automaticallyread aloud the text equivalent of a visual track,provide an auditory description of the impor-tant information of the visual track of a mul-timedia presentation. [Priority 1]

Synchronize the auditory descriptionwith the audio track as per checkpoint1.4. Refer to checkpoint 1.1 for infor-mation about textual equivalents forvisual information. Techniques for checkpoint 1.3

1.4 For any time-based multimedia presen-tation (e.g., a movie or animation), synchro-nize equivalent alternatives (e.g., captions orauditory descriptions of the visual track) withthe presentation. [Priority 1]

Techniques for checkpoint 1.4 1.5 Until user agents render text equiva-

lents for client-side image map links, provideredundant text links for each active region ofa client-side image map. [Priority 3]

Refer also to checkpoint 1.2 andcheckpoint 9.1. Techniques for checkpoint 1.5

Guideline 2. Don’t rely on color alone. Ensure that text and graphics are understand-able when viewed without color.If color alone is used to convey information,people who cannot differentiate between cer-tain colors and users with devices that havenon-color or non-visual displays will notreceive the information. When foregroundand background colors are too close to thesame hue, they may not provide sufficientcontrast when viewed using monochrome dis-plays or by people with different types of color deficits.

Checkpoints:2.1 Ensure that all information conveyed

with color is also available without color, forexample from context or markup. [Priority 1]

Techniques for checkpoint 2.1 2.2 Ensure that foreground and back-

ground color combinations provide sufficientcontrast when viewed by someone having color deficits or when viewed on a black andwhite screen. [Priority 2 for images, Priority 3for text].

Techniques for checkpoint 2.2

Guideline 3. Use markup and style sheetsand do so properly. Mark up documents with the proper structuralelements. Control presentation with style sheetsrather than with presentation elements andattributes.Using markup improperly—not according tospecification—hinders accessibility. Misusingmarkup for a presentation effect (e.g., using atable for layout or a header to change the fontsize) makes it difficult for users with special-ized software to understand the organizationof the page or to navigate through it. Further-more, using presentation markup rather thanstructural markup to convey structure (e.g.,constructing what looks like a table of data


in markup language attribute values and stylesheet property values. [Priority 2]

For example, in CSS, use ‘em’ or per-centage lengths rather than ‘pt’ or ‘cm’,which are absolute units. If absoluteunits are used, validate that the ren-dered content is usable (refer to thesection on validation). Techniques for checkpoint 3.4

3.5 Use header elements to convey docu-ment structure and use them according tospecification. [Priority 2]

For example, in HTML, use H2 toindicate a subsection of H1. Do notuse headers for font effects. Techniques for checkpoint 3.5

3.6 Mark up lists and list items properly.[Priority 2]

For example, in HTML, nest OL, UL,and DL lists properly. Techniques for checkpoint 3.6

3.7 Mark up quotations. Do not use quo-tation markup for formatting effects such asindentation. [Priority 2]

For example, in HTML, use the Q and BLOCKQUOTE elements tomarkup short and longer quotations,respectively. Techniques for checkpoint 3.7

Guideline 4. Clarify natural language usage. Use markup that facilitates pronunciation orinterpretation of abbreviated or foreign text.When content developers mark up naturallanguage changes in a document, speech syn-thesizers and braille devices can automaticallyswitch to the new language, making the docu-ment more accessible to multilingual users.Content developers should identify the pre-dominant natural language of a document’scontent (through markup or HTTP headers).Content developers should also provideexpansions of abbreviations and acronyms.

In addition to helping assistive technolo-gies, natural language markup allows searchengines to find key words and identify docu-ments in a desired language. Natural languagemarkup also improves readability of the Webfor all people, including those with learningdisabilities, cognitive disabilities, or people

with an HTML PRE element) makes it diffi-cult to render a page intelligibly to otherdevices (refer to the description of differencebetween content, structure, and presentation).

Content developers may be tempted to use(or misuse) constructs that achieve a desiredformatting effect on older browsers. Theymust be aware that these practices cause acces-sibility problems and must consider whetherthe formatting effect is so critical as to warrantmaking the document inaccessible to someusers.

At the other extreme, content developersmust not sacrifice appropriate markupbecause a certain browser or assistive technol-ogy does not process it correctly. For example,it is appropriate to use the TABLE element inHTML to mark up tabular information eventhough some older screen readers may nothandle side-by-side text correctly (refer tocheckpoint 10.3). Using TABLE correctly andcreating tables that transform gracefully (referto guideline 5) makes it possible for softwareto render tables other than as two-dimension-al grids.

Checkpoints:3.1 When an appropriate markup language

exists, use markup rather than images to con-vey information. [Priority 2]

For example, use MathML to mark upmathematical equations, and stylesheets to format text and control lay-out. Also, avoid using images to repre-sent text—use text and style sheetsinstead. Refer also to guideline 6 andguideline 11. Techniques for checkpoint 3.1

3.2 Create documents that validate to pub-lished formal grammars. [Priority 2]

For example, include a document typedeclaration at the beginning of a docu-ment that refers to a published DTD(e.g., the strict HTML 4.0 DTD). Techniques for checkpoint 3.2

3.3 Use style sheets to control layout andpresentation. [Priority 2]

For example, use the CSS ‘font’ prop-erty instead of the HTML FONT ele-ment to control font styles. Techniques for checkpoint 3.3

3.4 Use relative rather than absolute units

benefit people who access a table throughauditory means (e.g., a screen reader or anautomobile-based personal computer) or whoview only a portion of the page at a time (e.g.,users with blindness or low vision usingspeech output or a braille display, or otherusers of devices with small displays, etc.).

Checkpoints:5.1 For data tables, identify row and col-

umn headers. [Priority 1] For example, in HTML, use TD toidentify data cells and TH to identifyheaders. Techniques for checkpoint 5.1

5.2 For data tables that have two or morelogical levels of row or column headers, usemarkup to associate data cells and header cells.[Priority 1]

For example, in HTML, use THEAD,TFOOT, and TBODY to group rows,COL and COLGROUP to groupcolumns, and the “axis,” “scope,” and“headers” attributes, to describe morecomplex relationships among data. Techniques for checkpoint 5.2

5.3 Do not use tables for layout unless thetable makes sense when linearized. Otherwise,if the table does not make sense, provide analternative equivalent (which may be a lin-earized version). [Priority 2]

Note. Once user agents support stylesheet positioning, tables should not beused for layout. Refer also to check-point 3.3. Techniques for checkpoint 5.3

5.4 If a table is used for layout, do not useany structural markup for the purpose of visu-al formatting. [Priority 2]

For example, in HTML do not use theTH element to cause the content of a(non-table header) cell to be displayedcentered and in bold. Techniques for checkpoint 5.4

5.5 Provide summaries for tables. [Priority 3]For example, in HTML, use the “sum-mary” attribute of the TABLE element. Techniques for checkpoint 5.5

5.6 Provide abbreviations for header labels.[Priority 3]

For example, in HTML, use the “abbr”attribute on the TH element.

who are deaf. When abbreviations and natural language

changes are not identified, they may be inde-cipherable when machine-spoken or brailled.

Checkpoints:4.1 Clearly identify changes in the natural

language of a document’s text and any textequivalents (e.g., captions). [Priority 1]

For example, in HTML use the “lang”attribute. In XML, use “xml:lang.” Techniques for checkpoint 4.1

4.2 Specify the expansion of each abbrevia-tion or acronym in a document where it firstoccurs. [Priority 3]

For example, in HTML, use the “title”attribute of the ABBR andACRONYM elements. Providing the expansion in the main body of the document also helps documentusability. Techniques for checkpoint 4.2

4.3 Identify the primary natural languageof a document. [Priority 3]

For example, in HTML set the “lang”attribute on the HTML element. InXML, use “xml:lang.” Server operatorsshould configure servers to take advan-tage of HTTP content negotiationmechanisms ([RFC2068], section14.13) so that clients can automaticallyretrieve documents of the preferredlanguage.

Guideline 5. Create tables that transformgracefully. Ensure that tables have necessary markup to betransformed by accessible browsers and other useragents.Tables should be used to mark up truly tabu-lar information (“data tables”). Content devel-opers should avoid using them to lay outpages (“layout tables”). Tables for any use alsopresent special problems to users of screenreaders (refer to checkpoint 10.3).

Some user agents allow users to navigateamong table cells and access header and othertable cell information. Unless marked-upproperly, these tables will not provide useragents with the appropriate information.(Refer also to guideline 3.)

The following checkpoints will directly



6.5 Ensure that dynamic content is accessi-ble or provide an alternative presentation orpage. [Priority 2]

For example, in HTML, useNOFRAMES at the end of eachframeset. For some applications, server-side scripts may be more accessiblethan client-side scripts. Techniques for checkpoint 6.5

Refer also to checkpoint 11.4.

Guideline 7. Ensure user control of time-sensitive content changes. Ensure that moving, blinking, scrolling, or auto-updating objects or pages may be paused orstopped.Some people with cognitive or visual disabil-ities are unable to read moving text quicklyenough or at all. Movement can also causesuch a distraction that the rest of the pagebecomes unreadable for people with cognitivedisabilities. Screen readers are unable to readmoving text. People with physical disabilitiesmight not be able to move quickly or accu-rately enough to interact with movingobjects.

Note. All of the following checkpointsinvolve some content developer responsibilityuntil user agents provide adequate featurecontrol mechanisms.

Checkpoints:7.1 Until user agents allow users to control

flickering, avoid causing the screen to flicker.[Priority 1]

Note. People with photosensitiveepilepsy can have seizures triggered byflickering or flashing in the 4 to 59flashes per second (Hertz) range with apeak sensitivity at 20 flashes per sec-ond as well as quick changes from darkto light (like strobe lights). Techniques for checkpoint 7.1

7.2 Until user agents allow users to controlblinking, avoid causing content to blink (i.e.,change presentation at a regular rate, such asturning on and off ). [Priority 2]

Techniques for checkpoint 7.2 7.3 Until user agents allow users to freeze

moving content, avoid movement in pages.[Priority 2]

When a page includes moving con-

Techniques for checkpoint 5.6 Refer also to checkpoint 10.3.

Guideline 6. Ensure that pages featuringnew technologies transform gracefully. Ensure that pages are accessible even when newertechnologies are not supported or are turned off.Although content developers are encouragedto use new technologies that solve problemsraised by existing technologies, they shouldknow how to make their pages still work witholder browsers and people who choose to turnoff features.

Checkpoints:6.1 Organize documents so they may be

read without style sheets. For example, whenan HTML document is rendered withoutassociated style sheets, it must still be possibleto read the document. [Priority 1]

When content is organized logically, itwill be rendered in a meaningful orderwhen style sheets are turned off or notsupported. Techniques for checkpoint 6.1

6.2 Ensure that equivalents for dynamiccontent are updated when the dynamic con-tent changes. [Priority 1]

Techniques for checkpoint 6.2 6.3 Ensure that pages are usable when

scripts, applets, or other programmatic objectsare turned off or not supported. If this is notpossible, provide equivalent information onan alternative accessible page. [Priority 1]

For example, ensure that links thattrigger scripts work when scripts areturned off or not supported (e.g., donot use “javascript:” as the link target).If it is not possible to make the pageusable without scripts, provide a textequivalent with the NOSCRIPT ele-ment, or use a server-side script insteadof a client-side script, or provide analternative accessible page as per check-point 11.4. Refer also to guideline 1. Techniques for checkpoint 6.3

6.4 For scripts and applets, ensure thatevent handlers are input device-independent.[Priority 2]

Refer to the definition of device independence. Techniques for checkpoint 6.4

Guideline 9. Design for device-independence. Use features that enable activation of page ele-ments via a variety of input devices.Device-independent access means that theuser may interact with the user agent or docu-ment with a preferred input (or output)device—mouse, keyboard, voice, head wand,or other. If, for example, a form control canonly be activated with a mouse or other point-ing device, someone who is using the pagewithout sight, with voice input, or with a key-board or who is using some other non-point-ing input device will not be able to use theform.

Note. Providing text equivalents for imagemaps or images used as links makes it possiblefor users to interact with them without apointing device. Refer also to guideline 1.

Generally, pages that allow keyboard inter-action are also accessible through speech inputor a command line interface.

Checkpoints:9.1 Provide client-side image maps instead

of server-side image maps except where theregions cannot be defined with an availablegeometric shape. [Priority 1]

Refer also to checkpoint 1.1, check-point 1.2, and checkpoint 1.5. Techniques for checkpoint 9.1

9.2 Ensure that any element that has itsown interface can be operated in a device-independent manner. [Priority 2]

Refer to the definition of device independence. Refer also to guideline 8. Techniques for checkpoint 9.2

9.3 For scripts, specify logical event han-dlers rather than device-dependent event han-dlers. [Priority 2]

Techniques for checkpoint 9.3 9.4 Create a logical tab order through

links, form controls, and objects. [Priority 3] For example, in HTML, specify taborder via the “tabindex” attribute orensure a logical page design. Techniques for checkpoint 9.4

9.5 Provide keyboard shortcuts to impor-tant links (including those in client-side imagemaps), form controls, and groups of formcontrols. [Priority 3]

tent, provide a mechanism within ascript or applet to allow users to freezemotion or updates. Using style sheetswith scripting to create movementallows users to turn off or override theeffect more easily. Refer also to guide-line 8. Techniques for checkpoint 7.3

7.4 Until user agents provide the ability tostop the refresh, do not create periodicallyauto-refreshing pages. [Priority 2]

For example, in HTML, don’t causepages to auto-refresh with “HTTP-EQUIV=refresh” until user agentsallow users to turn off the feature. Techniques for checkpoint 7.4

7.5 Until user agents provide the ability tostop auto-redirect, do not use markup to redi-rect pages automatically. Instead, configurethe server to perform redirects. [Priority 2]

Techniques for checkpoint 7.5 Note. The BLINK and MARQUEE ele-

ments are not defined in any W3C HTMLspecification and should not be used. Referalso to guideline 11.

Guideline 8. Ensure direct accessibility ofembedded user interfaces. Ensure that the user interface follows principlesof accessible design: device-independent access to functionality, keyboard operability, self-voicing, etc.When an embedded object has its “own inter-face,” the interface—like the interface to thebrowser itself—must be accessible. If theinterface of the embedded object cannot bemade accessible, an alternative accessible solu-tion must be provided.

Note. For information about accessibleinterfaces, please consult the User AgentAccessibility Guidelines ([WAI-USERA-GENT]) and the Authoring Tool AccessibilityGuidelines ([WAI-AUTOOL]).

Checkpoint:8.1 Make programmatic elements such as

scripts and applets directly accessible or com-patible with assistive technologies [Priority 1if functionality is important and not present-ed elsewhere, otherwise Priority 2.]

Refer also to guideline 6. Techniques for checkpoint 8.1



rent page or some other) for all tables that layout text in parallel, word-wrapped columns.[Priority 3]

Note. Please consult the definition oflinearized table. This checkpoint bene-fits people with user agents (such assome screen readers) that are unable tohandle blocks of text presented side-by-side; the checkpoint should not dis-courage content developers from usingtables to represent tabular information. Techniques for checkpoint 10.3

10.4 Until user agents handle empty con-trols correctly, include default, place-holdingcharacters in edit boxes and text areas. [Priority 3]

For example, in HTML, do this forTEXTAREA and INPUT. Techniques for checkpoint 10.4

10.5 Until user agents (including assistivetechnologies) render adjacent links distinctly,include non-link, printable characters (sur-rounded by spaces) between adjacent links.[Priority 3]


Guideline 11. Use W3C technologies andguidelines. Use W3C technologies (according to specifica-tion) and follow accessibility guidelines. Whereit is not possible to use a W3C technology, ordoing so results in material that does not trans-form gracefully, provide an alternative version ofthe content that is accessible.The current guidelines recommend W3Ctechnologies (e.g., HTML, CSS, etc.) for sev-eral reasons:

✱ W3C technologies include “built-in”accessibility features.

✱ W3C specifications undergo earlyreview to ensure that accessibility issuesare considered during the design phase.

✱ W3C specifications are developed in anopen, industry consensus process.

Many non-W3C formats (e.g., PDF,Shockwave, etc.) require viewing with eitherplug-ins or stand-alone applications. Often,these formats cannot be viewed or navigatedwith standard user agents (including assistivetechnologies). Avoiding non-W3C and non-standard features (proprietary elements,

For example, in HTML, specify short-cuts via the “accesskey” attribute. Techniques for checkpoint 9.5

Guideline 10. Use interim solutions. Use interim accessibility solutions so that assis-tive technologies and older browsers will operatecorrectly.For example, older browsers do not allowusers to navigate to empty edit boxes. Olderscreen readers read lists of consecutive links asone link. These active elements are thereforedifficult or impossible to access. Also, chang-ing the current window or popping up newwindows can be very disorienting to users whocannot see that this has happened.

Note. The following checkpoints applyuntil user agents (including assistive technolo-gies) address these issues. These checkpointsare classified as “interim,” meaning that theWeb Content Guidelines Working Groupconsiders them to be valid and necessary toWeb accessibility as of the publication of thisdocument. However, the Working Group doesnot expect these checkpoints to be necessary inthe future, once Web technologies have incor-porated anticipated features or capabilities.

Checkpoints:10.1 Until user agents allow users to turn

off spawned windows, do not cause pop-upsor other windows to appear and do notchange the current window without inform-ing the user. [Priority 2]

For example, in HTML, avoid using aframe whose target is a new window. Techniques for checkpoint 10.1

10.2 Until user agents support explicitassociations between labels and form controls,for all form controls with implicitly associatedlabels, ensure that the label is properly posi-tioned. [Priority 2]

The label must immediately precede itscontrol on the same line (allowingmore than one control/label per line) orbe in the line preceding the control(with only one label and one controlper line). Refer also to checkpoint 12.4. Techniques for checkpoint 10.2

10.3 Until user agents (including assistivetechnologies) render side-by-side text correct-ly, provide a linear text alternative (on the cur-

inaccessible (original) page. [Priority 1] Techniques for checkpoint 11.4

Note. Content developers should onlyresort to alternative pages when other solu-tions fail because alternative pages are general-ly updated less often than “primary” pages. Anout-of-date page may be as frustrating as onethat is inaccessible since, in both cases, theinformation presented on the original page isunavailable. Automatically generating alterna-tive pages may lead to more frequent updates,but content developers must still be careful toensure that generated pages always makesense, and that users are able to navigate a siteby following links on primary pages, alterna-tive pages, or both. Before resorting to analternative page, reconsider the design of theoriginal page; making it accessible is likely toimprove it for all users.

Guideline 12. Provide context andorientation information. Provide context and orientation information tohelp users understand complex pages or elements.Grouping elements and providing contextualinformation about the relationships betweenelements can be useful for all users. Complexrelationships between parts of a page may bedifficult for people with cognitive disabilitiesand people with visual disabilities to interpret.

Checkpoints:12.1 Title each frame to facilitate frame

identification and navigation. [Priority 1] For example, in HTML use the “title”attribute on FRAME elements. Techniques for checkpoint 12.1

12.2 Describe the purpose of frames andhow frames relate to each other if it is notobvious by frame titles alone. [Priority 2]

For example, in HTML, use “longde-sc,” or a description link. Techniques for checkpoint 12.2

12.3 Divide large blocks of informationinto more manageable groups where naturaland appropriate. [Priority 2]

For example, in HTML, use OPT-GROUP to group OPTION elementsinside a SELECT; group form controlswith FIELDSET and LEGEND; usenested lists where appropriate; useheadings to structure documents, etc.

attributes, properties, and extensions) willtend to make pages more accessible to morepeople using a wider variety of hardware andsoftware. When inaccessible technologies(proprietary or not) must be used, equivalentaccessible pages must be provided.

Even when W3C technologies are used,they must be used in accordance with accessi-bility guidelines. When using new technolo-gies, ensure that they transform gracefully(Refer also to guideline 6.).

Note. Converting documents (from PDF,PostScript, RTF, etc.) to W3C markup lan-guages (HTML, XML) does not always createan accessible document. Therefore, validateeach page for accessibility and usability afterthe conversion process (refer to the section onvalidation). If a page does not readily convert,either revise the page until its original repre-sentation converts appropriately or provide anHTML or plain text version.

Checkpoints:11.1 Use W3C technologies when they are

available and appropriate for a task and use thelatest versions when supported. [Priority 2]

Refer to the list of references for information about where to find thelatest W3C specifications and [WAI-UA-SUPPORT] for information about user agent support for W3C technologies. Techniques for checkpoint 11.1

11.2 Avoid deprecated features of W3Ctechnologies. [Priority 2]

For example, in HTML, don’t use thedeprecated FONT element; use stylesheets instead (e.g., the ‘font’ propertyin CSS). Techniques for checkpoint 11.2

11.3 Provide information so that users mayreceive documents according to their prefer-ences (e.g., language, content type, etc.) [Priority 3]

Note. Use content negotiation wherepossible. Techniques for checkpoint 11.3

11.4 If, after best efforts, you cannot createan accessible page, provide a link to an alter-native page that uses W3C technologies, isaccessible, has equivalent information (orfunctionality), and is updated as often as the



explain available accessibility features. Techniques for checkpoint 13.3

13.4 Use navigation mechanisms in a con-sistent manner. [Priority 2]

Techniques for checkpoint 13.4 13.5 Provide navigation bars to highlight

and give access to the navigation mechanism.[Priority 3]

Techniques for checkpoint 13.5 13.6 Group related links, identify the

group (for user agents), and, until user agentsdo so, provide a way to bypass the group. [Priority 3]

Techniques for checkpoint 13.6 13.7 If search functions are provided,

enable different types of searches for differentskill levels and preferences. [Priority 3]

Techniques for checkpoint 13.7 13.8 Place distinguishing information at

the beginning of headings, paragraphs, lists,etc. [Priority 3]

Note. This is commonly referred to as“front-loading” and is especially help-ful for people accessing informationwith serial devices such as speechsynthesizers.

Techniques for checkpoint 13.8 13.9 Provide information about document

collections (i.e., documents comprising multi-ple pages.). [Priority 3]

For example, in HTML specify docu-ment collections with the LINK ele-ment and the “rel” and “rev” attributes.Another way to create a collection is bybuilding an archive (e.g., with zip, tarand gzip, stuffit, etc.) of the multiplepages. Note. The performance improvementgained by offline processing can makebrowsing much less expensive for peo-ple with disabilities who may bebrowsing slowly. Techniques for checkpoint 13.9

13.10 Provide a means to skip over multi-line ASCII art. [Priority 3]

Refer to checkpoint 1.1 and the exam-ple of ascii art in the glossary. Techniques for checkpoint 13.10

Guideline 14. Ensure that documents areclear and simple.


12.4 Associate labels explicitly with theircontrols. [Priority 2]

For example, in HTML use LABELand its “for” attribute. Techniques for checkpoint 12.4

Guideline 13. Provide clear navigationmechanisms. Provide clear and consistent navigation mecha-nisms—orientation information, navigationbars, a site map, etc.—to increase the likelihoodthat a person will find what they are looking forat a site.Clear and consistent navigation mechanismsare important to people with cognitive dis-abilities or blindness, and benefit all users.

Checkpoints:13.1 Clearly identify the target of each

link. [Priority 2] Link text should be meaningfulenough to make sense when read outof context—either on its own or aspart of a sequence of links. Link textshould also be terse. For example, in HTML, write “Infor-mation about version 4.3” instead of“click here.” In addition to clear linktext, content developers may furtherclarify the target of a link with aninformative link title (e.g., in HTML,the “title” attribute). Techniques for checkpoint 13.1

13.2 Provide metadata to add semanticinformation to pages and sites. [Priority 2]

For example, use RDF ([RDF]) toindicate the document’s author, thetype of content, etc. Note. Some HTML user agents canbuild navigation tools from documentrelations described by the HTMLLINK element and “rel” or “rev”attributes (e.g., rel=”next”, rel=”previ-ous”, rel=”index”, etc.). Refer also tocheckpoint 13.5. Techniques for checkpoint 13.2

13.3 Provide information about the gener-al layout of a site (e.g., a site map or table ofcontents). [Priority 2]

In describing site layout, highlight and

2. Validate syntax (e.g., HTML, XML, etc.). 3. Validate style sheets (e.g., CSS). 4. Use a text-only browser or emulator. 5. Use multiple graphic browsers, with:

✱ sounds and graphics loaded, ✱ graphics not loaded, ✱ sounds not loaded, ✱ no mouse, ✱ frames, scripts, style sheets, and

applets not loaded 6. Use several browsers, old and new. 7. Use a self-voicing browser, a screen

reader, magnification software, a smalldisplay, etc.

8. Use spell and grammar checkers. A personreading a page with a speech synthesizermay not be able to decipher the synthesiz-er’s best guess for a word with a spellingerror. Eliminating grammar problemsincreases comprehension.

9. Review the document for clarity and sim-plicity. Readability statistics, such as thosegenerated by some word processors maybe useful indicators of clarity and simplic-ity. Better still, ask an experienced(human) editor to review written contentfor clarity. Editors can also improve theusability of documents by identifyingpotentially sensitive cultural issues thatmight arise due to language or icon usage.

10. Invite people with disabilities to reviewdocuments. Expert and novice users withdisabilities will provide valuable feedbackabout accessibility or usability problemsand their severity.

Appendix B. — Glossary Accessible Content is accessible when it may be used bysomeone with a disability.

AppletA program inserted into a Web page.

Assistive technologySoftware or hardware that has been specificallydesigned to assist people with disabilities in car-rying out daily activities. Assistive technologyincludes wheelchairs, reading machines, devicesfor grasping, etc. In the area of Web Accessibil-ity, common software-based assistive technolo-

Ensure that documents are clear and simple sothey may be more easily understood.Consistent page layout, recognizable graphics,and easy to understand language benefit allusers. In particular, they help people with cog-nitive disabilities or who have difficulty read-ing. (However, ensure that images have textequivalents for people who are blind, have lowvision, or for any user who cannot or has chosen not to view graphics. Refer also to guideline 1.)

Using clear and simple language promoteseffective communication. Access to writteninformation can be difficult for people whohave cognitive or learning disabilities. Usingclear and simple language also benefits peoplewhose first language differs from your own,including those people who communicate pri-marily in sign language.

Checkpoints:14.1 Use the clearest and simplest language

appropriate for a site’s content. [Priority 1] Techniques for checkpoint 14.1

14.2 Supplement text with graphic or audi-tory presentations where they will facilitatecomprehension of the page. [Priority 3]


14.3 Create a style of presentation that isconsistent across pages. [Priority 3]


Appendix A. — ValidationValidate accessibility with automatic tools andhuman review. Automated methods are general-ly rapid and convenient but cannot identify allaccessibility issues. Human review can helpensure clarity of language and ease of navigation. Begin using validation methods at the earlieststages of development. Accessibility issuesidentified early are easier to correct and avoid.

Following are some important validationmethods, discussed in more detail in the section on validation in the Techniques Document. 1. Use an automated accessibility tool and

browser validation tool. Please note thatsoftware tools do not address all accessibil-ity issues, such as the meaningfulness oflink text, the applicability of a text equiva-lent, etc.



A braille display, commonly referred to asa “dynamic braille display,” raises or lowersdot patterns on command from an electronicdevice, usually a computer. The result is a lineof braille that can change from moment tomoment. Current dynamic braille displaysrange in size from one cell (six or eight dots)to an eighty-cell line, most having betweentwelve and twenty cells per line.

Content developerSomeone who authors Web pages or designsWeb sites.

Deprecated A deprecated element or attribute is one that

has been outdated by newer con-structs. Deprecat-ed elements maybecome obsoletein future versionsof HTML. Theindex of HTMLelements andattributes in theTechniques Docu-ment indicateswhich elements

and attributes are deprecated in HTML 4.0. Authors should avoid using deprecated ele-

ments and attributes. User agents should con-tinue to support for reasons of backwardcompatibility.

Device independentUsers must be able to interact with a useragent (and the document it renders) using thesupported input and output devices of theirchoice and according to their needs. Inputdevices may include pointing devices, key-boards, braille devices, head wands, micro-phones, and others. Output devices mayinclude monitors, speech synthesizers, andbraille devices.

Please note that “device-independent sup-port” does not meanthat user agents mustsupport every input oroutput device. Useragents should offer

gies include screen readers, screen magnifiers,speech synthesizers, and voice input softwarethat operate in conjunction with graphicaldesktop browsers (among other user agents).Hardware assistive technologies include alter-native keyboards and pointing devices.

ASCII art ASCII art refers to text characters and symbolsthat are combined to create an image. Forexample “;-)” is the smiley emoticon. The fol-lowing is an ascii figure showing the relation-ship between flash frequency andphotoconvulsive response in patients witheyes open and closed [skip over ascii figure orconsult a description of chart]:

Authoring tool HTML editors, document conversion tools,tools that generate Web content from databas-es are all authoring tools. Refer to the“Authoring Tool Accessibility Guidelines”([WAI-AUTOOLS]) for information aboutdeveloping accessible tools.

Backward compatible Design that continues to work with earlierversions of a language, program, etc.

BrailleBraille uses six raised dots in different patternsto represent letters and numbers to be read bypeople who are blind with their fingertips.The word “Accessible” in braille follows:

a logical construct (such as a header or list).The second sense emphasizes that a guidelineinspired by HTML could easily apply toanother markup language.

Note that some (SGML) elements havecontent that is rendered (e.g., the P, LI, orTABLE elements in HTML), some arereplaced by external content (e.g., IMG), andsome affect processing (e.g., STYLE andSCRIPT cause information to be processed bya style sheet or script engine). An element thatcauses text characters to be part of the docu-ment is called a text element.

Equivalent Content is “equivalent” to other content whenboth fulfill essentially the same function orpurpose upon presentation to the user. In thecontext of this document, the equivalent mustfulfill essentially the same function for theperson with a disability (at least insofar as isfeasible, given the nature of the disability andthe state of technology), as the primary con-tent does for the person without any disabili-ty. For example, the text “The Full Moon”might convey the same information as animage of a full moon when presented to users.Note that equivalent information focuses onfulfilling the same function. If the image ispart of a link and understanding the image iscrucial to guessing the link target, an equiva-lent must also give users an idea of the linktarget. Providing equivalent information forinaccessible content is one of the primaryways authors can make their documents acces-sible to people with disabilities.

As part of fulfilling the same function ofcontent an equivalent may involve a descrip-tion of that content (i.e., what the contentlooks like or sounds like). For example, inorder for users to understand the informationconveyed by a complex chart, authors shoulddescribe the visual information in the chart.

Since text content can be presented to theuser as synthesized speech, braille, and visual-ly-displayed text, these guidelines require textequivalents for graphic and audio informa-tion. Text equivalents must be written so thatthey convey all essential content. Non-textequivalents (e.g., an auditory description of avisual presentation, a video of a person telling

redundant input and output mechanisms forthose devices that are supported. For example,if a user agent supports keyboard and mouseinput, users should be able to interact with allfeatures using either the keyboard or themouse.

Document Content, Structure, and Presentation The content of a document refers to what itsays to the user through natural language,images, sounds, movies, animations, etc. Thestructure of a document is how it is organizedlogically (e.g., by chapter, with an introduc-tion and table of contents, etc.). An element(e.g., P, STRONG, BLOCKQUOTE inHTML) that specifies document structure iscalled a structural element. The presentationof a document is how the document is ren-dered (e.g., as print, as a two-dimensionalgraphical presentation, as an text-only presen-tation, as synthesized speech, as braille, etc.)An element that specifies document presenta-tion (e.g., B, FONT, CENTER) is called apresentation element.

Consider a document header, for example.The content of the header is what the headersays (e.g., “Sailboats”). In HTML, the headeris a structural element marked up with, forexample, an H2 element. Finally, the presen-tation of the header might be a bold block textin the margin, a centered line of text, a titlespoken with a certain voice style (like an auralfont), etc.

Dynamic HTML (DHTML) DHTML is the marketing term applied to amixture of standards including HTML, stylesheets, the Document Object Model [DOM1]and scripting. However, there is no W3C spec-ification that formally defines DHTML. Mostguidelines may be applicable to applicationsusing DHTML, however the following guide-lines focus on issues related to scripting andstyle sheets: guideline 1, guideline 3, guideline6, guideline 7, and guideline 9.

ElementThis document uses the term “element” bothin the strict SGML sense (an element is a syn-tactic construct) and more generally to meana type of content (such as video or sound) or



about actions, body language, graphics, andscene changes.

ImageA graphical presentation.

Image map An image that has been divided into regionswith associated actions. Clicking on an activeregion causes an action to occur.

When a user clicks on an active region of aclient-side image map, the user agent calcu-lates in which region the click occurred andfollows the link associated with that region.Clicking on an active region of a server-sideimage map causes the coordinates of the clickto be sent to a server, which then performssome action.

Content developers can make client-sideimage maps accessible by providing device-independent access to the same links associat-ed with the image map’s regions. Client-sideimage maps allow the user agent to provideimmediate feedback as to whether or not theuser’s pointer is over an active region.

Important Information in a document is important ifunderstanding that information is crucial tounderstanding the document.

Linearized tableA table rendering process where the contentsof the cells become a series of paragraphs (e.g.,down the page) one after another. The para-graphs will occur in the same order as the cellsare defined in the document source. Cellsshould make sense when read in order andshould include structural elements (that createparagraphs, headers, lists, etc.) so the pagemakes sense after linearization.

Link textThe rendered text content of a link.

Natural Language Spoken, written, or signed human languagessuch as French, Japanese, American Sign Lan-guage, and braille. The natural language ofcontent may be indicated with the “lang”attribute in HTML ([HTML40], section 8.1)

a story using sign language as an equivalentfor a written story, etc.) also improve accessi-bility for people who cannot access visualinformation or written text, including manyindividuals with blindness, cognitive disabili-ties, learning disabilities, and deafness.

Equivalent information may be providedin a number of ways, including throughattributes (e.g., a text value for the “alt”attribute in HTML and SMIL), as part of ele-ment content (e.g., the OBJECT in HTML),as part of the document’s prose, or via a linkeddocument (e.g., designated by the “longdesc”attribute in HTML or a description link).Depending on the complexity of the equiva-lent, it may be necessary to combine tech-niques (e.g., use “alt” for an abbreviatedequivalent, useful to familiar readers, in addi-tion to “longdesc” for a link to more completeinformation, useful to first-time readers). Thedetails of how and when to provide equivalentinformation are part of the Techniques Docu-ment ([TECHNIQUES]).

A text transcript is a text equivalent ofaudio information that includes spoken wordsand non-spoken sounds such as sound effects.A caption is a text transcript for the audio trackof a video presentation that is synchronizedwith the video and audio tracks. Captions aregenerally rendered visually by being superim-posed over the video, which benefits peoplewho are deaf and hard-of-hearing, and anyonewho cannot hear the audio (e.g., when in acrowded room). A collated text transcriptcombines (collates) captions with text descrip-tions of video information (descriptions of theactions, body language, graphics, and scenechanges of the video track). These text equiva-lents make presentations accessible to peoplewho are deaf-blind and to people who cannotplay movies, animations, etc. It also makes theinformation available to search engines.

One example of a non-text equivalent is anauditory description of the key visual ele-ments of a presentation. The description iseither a prerecorded human voice or a synthe-sized voice (recorded or generated on the fly).The auditory description is sysnchronizedwith the audio track of the presentation, usu-ally during natural pauses in the audio track.Auditory descriptions include information

they convey information that is independentof a particular font style.

Tabular information When tables are used to represent logical rela-tionships among data—text, numbers,images, etc., that information is called “tabu-lar information” and the tables are called“data tables.” The relationships expressed by atable may be rendered visually (usually on atwo-dimensional grid), aurally (often preced-ing cells with header information), or in oth-er formats.

Until user agents... In most of the checkpoints, content develop-ers are asked to ensure the accessibility of theirpages and sites. However, there are accessibili-ty needs that would be more appropriatelymet by user agents (including assistive tech-nologies). As of the publication of this docu-ment, not all user agents or assistivetechnologies provide the accessibility controlusers require (e.g., some user agents may notallow users to turn off blinking content, orsome screen readers may not handle tableswell). Checkpoints that contain the phrase“until user agents...” require content develop-ers to provide additional support for accessi-bility until most user agents readily availableto their audience include the necessary acces-sibility features.

Note. The W3C WAI Web site (refer to[WAI-UA-SUPPORT]) provides informationabout user agent support for accessibility fea-tures. Content developers are encouraged toconsult this page regularly for updated information.

User agentSoftware to access Web content, includingdesktop graphical browsers, text browsers,voice browsers, mobile phones, multimediaplayers, plug-ins, and some software assistivetechnologies used in conjunction withbrowsers such as screen readers, screen magni-fiers, and voice recognition software.

AcknowledgmentsWeb Content Guidelines Working Group Co-Chairs:

and the “xml:lang” attribute in XML ([XML],section 2.12).

Navigation Mechanism A navigation mechanism is any means bywhich a user can navigate a page or site. Sometypical mechanisms include:

✱ navigation bars A navigation bar is a collection of links to

the most important parts of a document or site.✱ site mapsA site map provides a global view of the

organization of a page or site. ✱ table of contentsA table of contents generally lists (and links

to) the most important sections of a document.

Personal Digital Assistant (PDA) A PDA is a small, portable computing device.Most PDAs are used to track personal datasuch as calendars, contacts, and electronicmail. A PDA is generally a handheld devicewith a small screen that allows input from var-ious sources.

Screen magnifier A software program that magnifies a portionof the screen, so that it can be more easilyviewed. Screen magnifiers are used primarilyby individuals with low vision.

Screen readerA software program that reads the contents ofthe screen aloud to a user. Screen readers areused primarily by individuals who are blind.Screen readers can usually only read text thatis printed, not painted, to the screen.

Style sheets A style sheet is a set of statements that specifypresentation of a document. Style sheets mayhave three different origins: they may be writ-ten by content providers, created by users, orbuilt into user agents. In CSS ([CSS2]), theinteraction of content provider, user, and useragent style sheets is called the cascade.

Presentation markup is markup thatachieves a stylistic (rather than structuring)effect such as the B or I elements in HTML.Note that the STRONG and EM elements arenot considered presentation markup since



tion,” V. Apparao, S. Byrne, M. Champion, S. Isaacs, I.

Jacobs, A. Le Hors, G. Nicol, J. Robie, R. Sutor, C. Wil-

son, and L. Wood, eds., 1 October 1998. The DOM Lev-

el 1 Recommendation is:

http://www.w3.org/TR/1998/REC-DOM-Level-1-

19981001.

The latest version of DOM Level 1 is available at:

http://www.w3.org/TR/REC-DOM-Level-1

[HTML40]

“HTML 4.0 Recommendation,” D. Raggett, A. Le

Hors, and I. Jacobs, eds., 17 December 1997, revised

24 April 1998. The HTML 4.0 Recommendation is:

http://www.w3.org/TR/1998/REC-html40-19980424.

The latest version of HTML 4.0 is available at:

http://www.w3.org/TR/REC-html40.

[HTML32]

“HTML 3.2 Recommendation,” D. Raggett, ed., 14

January 1997. The latest version of HTML 3.2 is avail-

able at: http://www.w3.org/TR/REC-html32.

[MATHML]

“Mathematical Markup Language,” P. Ion and R. Miner,

eds., 7 April 1998. The MathML 1.0 Recommendation is:

http://www.w3.org/TR/1998/REC-MathML-19980407.

The latest version of MathML 1.0 is available at:

http://www.w3.org/TRREC-MathML.

[PNG]

“PNG (Portable Network Graphics) Specification,” T.

Boutell, ed., T. Lane, contributing ed., 1 October 1996.

The latest version of PNG 1.0 is:

http://www.w3.org/TR/REC-png.

[RDF]

“Resource Description Framework (RDF) Model and

Syntax Specification,” O. Lassila, R. Swick, eds., 22

February 1999. The RDF Recommendation is:

http://www.w3.org/TR/1999/REC-rdf-syntax-19990222.

The latest version of RDF 1.0 is available at:

http://www.w3.org/TR/REC-rdf-syntax

[RFC2068]

“HTTP Version 1.1,” R. Fielding, J. Gettys, J. Mogul,

H. Frystyk Nielsen, and T. Berners-Lee, January 1997.

[SMIL]

“Synchronized Multimedia Integration Language

(SMIL) 1.0 Specification,” P. Hoschka, ed., 15 June

1998. The SMIL 1.0 Recommendation is:

http://www.w3.org/TR/1998/REC-smil-19980615

The latest version of SMIL 1.0 is available at:

http://www.w3.org/TR/REC-smil

[TECHNIQUES]

“Techniques for Web Content Accessibility Guidelines

1.0,” W. Chisholm, G. Vanderheiden, I. Jacobs, eds.

This document explains how to implement the check-

✱ Chuck Letourneau, Starling Access Ser-vices

✱ Gregg Vanderheiden, Trace Researchand Development

W3C Team contacts: ✱ Judy Brewer and Daniel Dardailler

We wish to thank the following people whohave contributed their time and valuable com-ments to shaping these guidelines:

Harvey Bingham, Kevin Carey, ChetzColwell, Neal Ewers, Geoff Freed, AlGilman, Larry Goldberg, Jon Gunder-son, Eric Hansen, Phill Jenkins,Leonard Kasday, George Kerscher, Mar-ja-Riitta Koivunen, Josh Krieger, ScottLuebking, William Loughborough,Murray Maloney, CharlesMcCathieNevile, MegaZone (Liv-ingston Enterprises), Masafumi Nakane,Mark Novak, Charles Oppermann,Mike Paciello, David Pawson, MichaelPieper, Greg Rosmaita, Liam Quinn,Dave Raggett, T.V. Raman, RobertSavellis, Jutta Treviranus, Steve Tyler,Jaap van Lelieveld, and Jason White

The original draft of this document isbased on “The Unified Web Site AccessibilityGuidelines” ([UWSAG]) compiled by theTrace R & D Center at the University of Wis-consin. That document includes a list of addi-tional contributors.

ReferencesFor the latest version of any W3C specification please

consult the list of W3C Technical Reports.

[CSS1]

“CSS, level 1 Recommendation,” B. Bos, H. Wium Lie,

eds., 17 December 1996, revised 11 January 1999. The

CSS1 Recommendation is:

http://www.w3.org/TR/1999/REC-CSS1-19990111.

The latest version of CSS1 is available at:

http://www.w3.org/TR/REC-CSS1.

[CSS2]

“CSS, level 2 Recommendation,” B. Bos, H. Wium Lie,

C. Lilley, and I. Jacobs, eds., 12 May 1998. The CSS2

Recommendation is:

http://www.w3.org/TR/1998/REC-CSS2-19980512.

The latest version of CSS2 is available at:

http://www.w3.org/TR/REC-CSS2.

[DOM1]

“Document Object Model (DOM) Level 1 Specifica-

points defined in “Web Content Accessibility

Guidelines 1.0.” The latest draft of the tech-

niques is available at:

http://www.w3.org/TR/WAI-WEBCON-

TENT-TECHS/

[WAI-AUTOOLS]

“Authoring Tool Accessibility Guidelines,” J.

Treviranus, J. Richards, I. Jacobs, C.

McCathieNevile, eds. The latest Working

Draft of these guidelines for designing acces-

sible authoring tools is available at:

http://www.w3.org/TR/WAI-AUTOOLS/

[WAI-UA-SUPPORT]

This page documents known support by user

agents (including assistive technologies) of

some accessibility features listed in this docu-

ment. The page is available at:

http://www.w3.org/WAI/Resources/WAI-

UA-Support

[WAI-USERAGENT]

“User Agent Accessibility Guidelines,” J.

Gunderson and I. Jacobs, eds. The latest

Working Draft of these guidelines for design-

ing accessible user agents is available at:

http://www.w3.org/TR/WAI-USERA-

GENT/

[WCAG-ICONS]

Information about conformance icons for

this document and how to use them is avail-

able at http://www.w3.org/WAI/WCAG1-

Conformance.html

[UWSAG]

“The Unified Web Site Accessibility Guide-

lines,” G. Vanderheiden, W. Chisholm, eds.

The Unified Web Site Guidelines were com-

piled by the Trace R & D Center at the Uni-

versity of Wisconsin under funding from the

National Institute on Disability and Rehabil-

itation Research (NIDRR), U.S. Dept. of

Education. This document is available at:

http://www.tracecenter.org/docs/html_guide-

lines/version8.htm

[XML]

“Extensible Markup Language (XML) 1.0.,”

T. Bray, J. Paoli, C.M. Sperberg-McQueen,

eds., 10 February 1998. The XML 1.0 Rec-

ommendation is: http://www.w3.org/TR/

1998/REC-xml-19980210.

The latest version of XML 1.0 is available at:

http://www.w3.org/TR/REC-xml

web content accessibility guidelines 1.0

Documents