Audrey
Laurie
Alice
... End example. 3.4 Keyboard access Checkpoints in this section: 9.2. 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 should always 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: Image map links 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. Keyboard shortcuts 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. Tabbing order 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. 3.4.1 Device-independent control for embedded interfaces 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. 3.5 Navigation Checkpoints in this section: 14.3, 13.4, 13.5, 13.3, 13.7, and 13.2. 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: 1. navigation bars 2. the primary content of a page 3. 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. 3.6 Comprehension Checkpoints in this section: 14.1, 13.8, and 14.2. The following sections discuss techniques for helping comprehension of a page or site. 3.6.1 Writing style The 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. 1. 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 headers so that users can scan a page quickly for information rather than reading it in detail. 2. 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. 3. Limit each paragraph to one main idea. 4. Avoid slang, jargon, and specialized meanings of familiar words, unless defined within your document. 5. Favor words that are commonly used. For example, use "begin" rather than "commence" or use "try" rather than "endeavor." 6. Use active rather than passive verbs. 7. 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. 3.6.2 Multimedia equivalents For 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: 1. A chart of complex data, such as sales figures of a business for the past fiscal year. 2. 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. 3. 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. 3.7 Content negotiation Checkpoints in this section: 11.3. 1. Instead of including links such as "Here is the French version of this document", use content negotiation so that the French version is served to clients requesting French versions of documents. 2. If not possible to use content negotiation, indicate content type or language through markup (e.g., in HTML use "type" and "hreflang"). 3.8 Automatic page refresh Checkpoints in this section: 7.4, and 7.5. 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: 1. 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 by 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. 2. Replace the page that would be redirected with a static page containing a normal link to the new page. Note. Both checkpoint 7.4 and checkpoint 7.5 address problems posed by legacy user agents. Newer user agents should disable refresh and substitute a link to new information at the top of the page. The following are deprecated HTML examples. The first changes the user's page at page at regular intervals. Content developers should not use this technique to simulate "push" technology. Developers cannot predict how much time a user will require to read a page; premature refresh can disorient users. Content developers should avoid periodic refresh and allow users to choose when they want the latest information. Deprecated example.
...Information... The following HTML example (using the META element) forwards the user from one page to another after a timeout. However, users should not redirect users with this markup since is non-standard, it disorients users, and it can disrupt a browser's history of visited pages. Deprecated example.
If your browser supports Refresh, you'll be transported to our new site in 5 seconds, otherwise, select the link manually. 3.9 Screen flicker Checkpoints in this section: 7.1. 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). 3.10 Bundled documents Checkpoints in this section: 13.9. 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. 3.11 Validation 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, 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 1.0". 3.11.1 Automatic validators A 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: 1. An automated accessibility validation tool such as Bobby (refer to [BOBBY]). 2. An HTML validation service such as the W3C HTML Validation Service (refer to [HTMLVAL]). 3. A style sheets validation service such as the W3C CSS Validation Service (refer to [CSSVAL]). 3.11.2 Repair tools Validators 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. 3.11.3 User scenarios Keep 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: 1. 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]). 2. 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. 3. 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. 4. 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. 3.11.4 Spell and grammar checks A 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. 3.12 Browser Support Checkpoints in this section: 11.1. Note. At the time of this writing, not all user agents support some of the (new) HTML 4.0 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. _________________________________________________________________ 4 HTML Techniques The following sections list some techniques for designing accessible HTML documents. The sections are organized by topic (and mirror the organization of the HTML 4.0 specification, [HTML40]). 4.1 Document structure and metadata Checkpoints in this section: 3.2 Content developers should use structural markup and use it according to specification. Structural elements and attribute (refer to the index of HTML elements and attributes to identify them) promote consistency in documents and supply information to other tools (e.g., indexing tools, search engines, programs that extract tables to databases, navigation tools that use header elements, and automatic translation software that translates text from one language into another. 4.1.1 Metadata Checkpoints in this section: 13.2. Some structural elements provide information about the document itself. This is called "metadata" about the document -- Metadata is information about data. Well-crafted metadata can provide important orientation information to users. HTML elements that provide useful information about a document include: * TITLE: The document title. Note that the (mandatory) TITLE element, which only appears once in a document, is different from the "title" attribute, which applies to almost every HTML 4.0 element. Content developers should use the "title" attribute in accordance with the HTML 4.0 specification. For example, "title" should be used with links to provide information about the target of the link. * ADDRESS: Can be used to provide information about the creator of the page. * LINK: Can be used to indicate alternative documents (different structure, different language, different target device, etc.). * The META element can specify arbitrary metadata for a document. Please refer to the section on automatic page refresh for information on why META should not be used to redirect pages. 4.1.2 Section headers Checkpoints in this section: 3.5. Sections should be introduced with the HTML header elements (H1-H6). Other markup may complement these elements to improve presentation (e.g., the HR element to create a horizontal dividing line), but visual presentation is not sufficient to identify document sections. Since some users skim through a document by navigating its headings, it is important to use them appropriately to convey document structure. Users should order heading elements properly. For example, in HTML, H2 elements should follow H1 elements, H3 elements should follow H2 elements, etc. Content developers should not "skip" levels (e.g., H1 directly to H3). Do not use headings to create font effects; use style sheets to change font styles for example. Note that in HTML, heading elements (H1 - H6) only start sections, they don't contain them as element content. The following HTML markup shows how style sheets may be used to control the appearance of a header and the content that follows: Example.
And with a certain je ne sais quoi,
she entered both the room, and his life, forever. My name
is Natasha,
she said. Piacere,
he replied in impeccable Italian, locking the door.
End example.
Identifying changes in language are important for a number of reasons:
1. Users who are reading the document in braille will be able to
substitute the appropriate control codes (markup) where language
changes occur to ensure that the braille translation software will
generate the correct characters (accented characters, for
instance). These control codes also prevent braille contractions
from being generated, which could further confuse the user.
Braille contractions combine commonly used groups of characters
that usually appear in multiple cells into a single cell. For
example, "ing" which usually takes up three cells (one for each
character) can be contracted into a single cell.
2. Similarly, speech synthesizers that "speak" multiple languages
will be able to generate the text in the appropriate accent with
proper pronunciation. If changes are not marked, the synthesizer
will try its best to speak the words in the primary language it
works in. Thus, the French word for car, "voiture" would be
pronounced "voter."
3. Users who are unable to translate between languages themselves,
will be able to have unfamiliar languages translated by machine
translators.
It is also good practice to identify the primary language of a
document, either with markup (as shown below) or through HTTP headers.
Example.
....rest of an HTML document written in French...
End example.
4.3 Text markup
The following sections discuss ways to add structure to pieces of
text.
4.3.1 Emphasis
Checkpoints in this section: 3.3.
The proper HTML elements should be used to mark up emphasis: EM and
STRONG. The B and I elements should not be used; they are used to
create a visual presentation effect. The EM and STRONG elements were
designed to indicate structural emphasis that may be rendered in a
variety of ways (font style changes, speech inflection changes, etc.)
4.3.2 Acronyms and abbreviations
Checkpoints in this section: 4.2.
Mark up abbreviations and acronyms with ABBR and ACRONYM and use
"title" to indicate the expansion:
Example.
Welcome to the WWW! End example. 4.3.3 Quotations Checkpoints in this section: 3.7. The Q and BLOCKQUOTE elements mark up inline and block quotations, respectively. Example. This example marks up a longer quotation with BLOCKQUOTE:
End example. 4.3.4 Markup and style sheets rather than images: The example of math Checkpoints in this section: 3.1. Using markup (and style sheets) where possible rather than images (e.g., a mathematical equation) promotes accessibility for the following reasons: * Text may be magnified or interpreted as speech or braille. * Search engines can use text information. As an example, consider these techniques for putting mathematics on the Web: * Ensure that users know what variables represent, for example, in the equation "F = m * a", indicate that F= Force, m = mass, a = acceleration. * For straightforward equations, use characters, as in "x + y = z" * For more complex equations, mark them up with MathML ([MATHML]) or TeX. Note. MathML can be used to create very accessible documents but currently is not as widely supported or used as TeX. * Provide a text description of the equation and, where possible, use character entity references to create the mathematical symbols. A text equivalent must be provided if the equation is represented by one or more images. TeX is commonly used to create technical papers which are then converted to HTML for publication on the Web. However, converters tend to generate images, use deprecated markup, and use tables for layout. Consequently, content providers should: 1. Make the original TeX (or LaTeX) document available on the Web. There is a system called "AsTeR" ([ASTER]) that can create an auditory rendition of TeX and LaTeX documents. Also, IBM has a plug-in for Netscape and Internet Explorer that reads TeX/LaTeX documents and some of MathML (refer to [HYPERMEDIA]). 2. Ensure that the HTML created by the conversion process is accessible. Provide a single description of the equation (rather than "alt" text on every generated image as there may be small images for bits and pieces of the equation). 4.3.5 Miscellaneous structural markup The HTML 4.0 specification defines the following structural elements for miscellaneous markup needs: CITE Contains a citation or a reference to other sources. DFN Indicates that this is the defining instance of the enclosed term. CODE Designates a fragment of computer code. SAMP Designates sample output from programs, scripts, etc. KBD Indicates text to be entered by the user. VAR Indicates an instance of a variable or program argument. INS Indicates text inserted into a document. DEL Indicates text deleted from a document. 4.4 Lists Checkpoints in this section: 3.6. The HTML list elements DL, UL, and OL should only be used to create lists, not for formatting effects such as indentation. Ordered lists help non-visual users navigate. Non-visual users may "get lost" in lists, especially in nested lists and those that do not indicate the specific nest level for each list item. Until user agents provide a means to identify list context clearly (e.g., by supporting the ':before' pseudo-element in CSS2), content developers should include contextual clues in their lists. For numbered lists, compound numbers are more informative than simple numbers. Thus, a list numbered "1, 1.1, 1.2, 1.2.1, 1.3, 2, 2.1," provides more context than the same list without compound numbers, which might be formatted as follows: 1. 1. 2. 1. 3. 2. 1. and would be spoken as "1, 1, 2, 1, 2, 3, 2, 1", conveying no information about list depth. [CSS1] and [CSS2] allow users to control number styles (for all list, not just ordered) through user style sheets. Example. The following CSS2 style sheet shows how to specify compound numbers for nested lists created with either UL or OL elements. Items are numbered as "1", "1.1", "1.1.1", etc. End example. Until either CSS2 is widely supported or user agents allow users to control rendering of lists through other means, authors should consider providing contextual clues in unnumbered nested lists. Non-visual users may have difficulties knowing where a list begins and ends and where each list item starts. For example, if a list entry wraps to the next line on the screen, it may appear to be two separate items in the list. This may pose a problem for legacy screen readers. 4.4.1 Use style sheets to change list bullets To change the "bullet" style of unordered list items created with the LI element, use style sheets. In CSS, it is possible to specify a fallback bullet style (e.g., 'disc') if a bullet image cannot be loaded. Example.Remuneration! O! that's the Latin word for three farthings. --- William Shakespeare (Love's Labor Lost).
Audrey
Laurie
Alice
Roth IRA
401(k)| Name | Cups | Type of Coffee | Sugar? |
|---|---|---|---|
| T. Sexton | 10 | Espresso | No |
| J. Dinnen | 5 | Decaf | Yes |
| Name | Cups | Type of Coffee | Sugar? |
|---|---|---|---|
| T. Sexton | 10 | Espresso | No |
| J. Dinnen | 5 | Decaf | Yes |
| Meals | Hotels | Transport | subtotals | |
|---|---|---|---|---|
| San Jose | ||||
| 25-Aug-97 | 37.74 | 112.00 | 45.00 | |
| 26-Aug-97 | 27.28 | 112.00 | 45.00 | |
| subtotals | 65.02 | 224.00 | 90.00 | 379.02 |
| Seattle | ||||
| 27-Aug-97 | 96.25 | 109.00 | 36.00 | |
| 28-Aug-97 | 35.00 | 109.00 | 36.00 | |
| subtotals | 131.25 | 218.00 | 72.00 | 421.25 |
| Totals | 196.27 | 442.00 | 162.00 | 800.27 |
End example.
When using OBJECT, specify a text equivalent in the body of the OBJECT
element:
Example.
End example.
When a short text equivalent does not suffice to adequately convey the
function or role of an image, provide additional information in a file
designated by the "longdesc" attribute:
Example.
In sales97.html:
A chart showing how sales in 1997 progressed. The chart
is a bar-chart showing percentage increases in sales
by month. Sales in January were up 10% from December 1996,
sales in February dropped 3%, ..
End example.
For user agents that don't support "longdesc", provide a description
link as well next to the graphic:
Example.
[D]
End example.
When using OBJECT, specify the the longer text equivalent within the
element's content:
Example.
End example.
Note that OBJECT content, unlike "alt" text, can include markup. Thus,
content developers can provide a link to additional information from
within the OBJECT element:
Example.
End example.
4.7.2 Invisible d-links
Note. Invisible d-links are deprecated in favor of the "longdesc"
attribute.
An invisible d-link is a small (1-pixel) or transparent image whose
"alt" attribute value is "D-link" or "D" and is part of the content of
an A element. Like other d-links, it refers to a text equivalent of
the associated image. Like other links, users can tab to it. Invisible
d-links thus provide a (temporary) solution for designers who wish to
avoid visible d-links for stylistic reasons.
4.7.3 Ascii art
Checkpoints in this section: 13.10.
Avoid ascii art (character illustrations) and use real images instead
since it is easier to supply a text equivalent for images. However, if
ascii art must be used provide a link to jump over the ASCII art, as
follows.
Example.
skip over ASCII art caption for ASCII art End example. ASCII art may also be marked up as follows [skip over ascii figure or consult a description of chart]: Example. % __ __ __ __ __ __ __ __ __ __ __ __ __ __ 100 | * | 90 | * * | 80 | * * | 70 | @ * | 60 | @ * | 50 | * @ * | 40 | @ * | 30 | * @ @ @ * | 20 | | 10 | @ @ @ @ @ | 0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 Flash frequency (Hz) End example. Another option for smaller ascii art is to use an ABBR element with "title". Example.
:-)
End example.
If the ASCII art is complex, ensure that the text equivalent
adequately describes it.
Another way to replace ascii art is to use human language substitutes.
For example, [Reference]
[Audio Visual Lab]
End example.
* If other approaches don't make the image map accessible, create an
alternative page that is accessible.
Server-side and client-side image maps may be used as submit buttons
in Forms. For more information, refer to the section Graphical
buttons.
4.8 Applets and other programmatic objects
While applets may be included in a document with either the APPLET or
OBJECT element, OBJECT is the preferred method.
4.8.1 Text equivalents for applets and programmatic objects
If OBJECT is used, provide a text equivalent in the content of the
element:
Example.
End example.
A more complex example takes advantage of the fact the OBJECT elements
may be embedded to provide for alternative representations of
information:
Example.
End example.
If APPLET is used, provide a text equivalent with the "alt" attribute
and in the content in the APPLET element. This enables the content to
transform gracefully for those user agents that only support one of
the two mechanisms ("alt" or content).
Deprecated example.
4.8.2 Directly accessible applets
Checkpoints in this section: 8.1
If an applet (created with either OBJECT or APPLET) requires user
interaction (e.g., the ability to manipulate a physics experiment)
that cannot be duplicated in an alternative format, make the applet
directly accessible.
For more information about developing accessible applets, please refer
to [JAVAACCESS] and [IBMJAVA]. These companies have been developing an
Accessibility API as well as making the Java Swing classes accessible.
4.8.3 Audio and Video produced by dynamic objects
Checkpoints in this section: 8.1 and 1.4.
Provide a text equivalent as for an image and auditory descriptions of
visual information and captions where necessary. If an applet creates
motion, developers should provide a mechanism for freezing this motion
(for an example, refer to [TRACE]). Also, please refer to the next
section for information about making audio and video presentations
accessible.
4.9 Audio and video
4.9.1 Audio information
Auditory presentations must be accompanied by text transcripts,
textual equivalents of auditory 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.
Example.
Captions for a scene from "E.T." The phone rings three times, then is
answered.
[phone rings]
[ring]
[ring]
Hello?"
End example.
Until the format you are using supports alternative tracks, two
versions of the movie could be made available, one with captions and
descriptive video, 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.
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].
4.9.2 Visual information and motion
Checkpoints in this section: 1.3, and 7.3.
Auditory 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. Auditory descriptions are used primarily
by people who are blind to follow the action and other non-auditory
information in video material.
Example.
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 auditory 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.
End example.
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 auditory description is not necessary.
For movies, provide auditory descriptions that are synchronized with
the original audio. Refer to the section on audio information for more
information about multimedia formats.
4.9.3 Collated text transcripts
Collated 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
auditory description.
4.9.4 Text equivalents for multimedia
When necessary, a text equivalent should be provided for visual
information to enable understanding of the page. For example, consider
a repeating animation that shows cloud cover and precipitation as part
of a weather status report. Since the animation is supplementing the
rest of the weather report (that is presented in natural language -
text), a less verbose description of the animation is necessary.
However, if the animation appears in a pedagogical setting where
students are learning about cloud formations in relation to land mass,
then the animation ought to be described for those who can not view
the animation but who also want to learn the lesson.
See also the section on text style for controlling blinking.
4.9.5 Embedding multimedia objects
Other objects, such as those requiring a plug-in, should also use the
OBJECT element. However, for backward compatibility with Netscape
browsers, use the proprietary EMBED element within the OBJECT element
as follows:
Deprecated example.
End example.
For more information refer to [MACROMEDIA].
4.10 Frames
For visually enabled users, frames may organize a page into different
zones. For non-visual users, relationships between the content in
frames (e.g., one frame has a table of contents, another the contents
themselves) must be conveyed through other means.
Frames as implemented today (with the FRAMESET, FRAME, and IFRAME
elements) are problematic for several reasons:
* Without scripting, they tend to break the "previous page"
functionality offered by browsers.
* It is impossible to refer to the "current state" of a frameset
with a URI; once a frameset changes contents, the original URI no
longer applies.
* Opening a frame in a new browser window can disorient or simply
annoy users.
In the following sections, we discuss how to make frames more
accessible. We also provide an alternative to frames that uses HTML
4.0 and CSS and addresses many of the limitations of today's frame
implementations.
4.10.1 Title frames for easy orientation
Checkpoints in this section: 12.1.
Example.
Use the "title" attribute to name frames.
Visit a beautiful grove of
oranges
the initial title of the frame ("Apples") will no longer match the
current content of the frame ("Oranges").
4.10.5 Avoid opening a new window as the target of a frame
Checkpoints in this section: 10.1.
Content developers should avoid specifying a new window as the target
of a frame with target="_blank".
4.10.6 Alternatives to frames
One of the most common uses of frames is to split the user's browser
window into two parts: a navigation window and a content window. As an
alternative to frames, we encourage you to try the following:
1. Create one document for the navigation mechanism (call it
"nav.html"). A separate document means that the navigation
mechanism may be shared by more than one document.
2. In each document requiring the navigation mechanism, include it at
the bottom of the document with the following (or similar) OBJECT
markup:
Example.
Putting the navigation mechanism at the end of the document means
that when style sheets are turned off, users have access to the
document's important information first.
3. Use style sheets to position the navigation mechanism where you
want on the screen. For example, the following CSS rule floats the
navigation bar to the left of the page and makes it take up 25% of
the available horizontal space:
OBJECT { float: left; width: 25% }
The following CSS rule attaches the navigation mechanism to the
bottom-left corner of the page of the page and keeps it there even
if the user scrolls down the page:
OBJECT { position: fixed; left: 0; bottom: 0 }
Note. Navigation mechanisms or other content may be inserted in a
document by means of server-side includes.
4.11 Forms
This section discusses the accessibility of forms and form controls
that one can put in a FORM element.
4.11.1 Make controls keyboard accessible
Checkpoints in this section: 9.4 and 9.5.
Refer to the section on keyboard access for more information.
4.11.2 Group form controls
Content developers should group information where natural and
appropriate. When form controls can be grouped into logical units, use
the FIELDSET element and label those units with the LEGEND element:
Example.
This is an
Once upon a time...
Note. As of the writing of this document, the CSS pseudo-element
':first-letter', which allows content developers to refer to the first
letter of a chunk of text, is not widely supported.
5.5 Colors
Checkpoints in this section: 2.1 and 2.2.
Use these CSS properties to specify colors:
* 'color', for foreground text color.
* 'background-color', for background colors.
* 'border-color', 'outline-color' for border colors.
* For link colors, refer to the :link, :visited, and :active
pseudo-classes.
Ensure that information is not conveyed through color alone. For
example, when asking for input from users, do not write "Please select
an item from those listed in green." Instead, ensure that information
is available through other style effects (e.g., a font effect) and
through context (e.g,. comprehensive text links).
For instance, in this document, examples are styled by default
(through style sheets) as follows:
* They are surrounded by a border.
* They use a different background color.
* They begin with the word "Example" (or "Deprecated Example".
* They also end with the phrase "End example", but that phrase is
hidden by default with 'display: none'. For user agents that don't
support style sheets or when style sheets are turned off, this
text helps delineate the end of an example for readers who may not
be able to see the border around the example.
Quicktest! To test whether your document still works without colors,
examine it with a monochrome monitor or browser colors turned off.
Also, try setting up a color scheme in your browser that only uses
black, white, and the four browser-safe greys and see how your page
holds up.
Quicktest! To test whether color contrast is sufficient to be read by
people with color deficiencies or by those with low resolution
monitors, print pages on a black and white printer (with backgrounds
and colors appearing in grayscale). Also try taking the printout and
copying it for two or three generations to see how it degrades. This
will show you where you need to add redundant cues (example:
hyperlinks are usually underlined on Web pages), or whether the cues
are two small or indistinct to hold up well.
For more information about colors and contrasts, refer to
[LIGHTHOUSE].
5.6 Layout, positioning, layering, and alignment
Layout, positioning, layering, and alignment should be done through
style sheets (notably by using CSS floats and absolute positioning):
* 'text-indent', 'text-align', 'word-spacing', 'font-stretch'. Each
of these properties allows users to control spacing without adding
additional spaces. Use 'text-align: center' instead of the
deprecated CENTER element.
* 'margin', 'margin-top', 'margin-right', 'margin-bottom',
'margin-left'. With these properties, authors can create space on
four sides of an element's content instead of adding non-breaking
spaces ( ), which are non-standard mark-up, to create space
around an element.
* 'float', 'position', 'top', 'right', 'bottom', 'left'. With these
properties, the user can control the visual position of almost any
element in a manner independent of where the element appears in
the document. Authors should always design documents that make
sense without style sheets (i.e., the document should be written
in a "logical" order) and then apply style sheets to achieve
visual effects. The positioning properties may be used to create
margin notes (which may be automatically numbered), side bars,
frame-like effects, simple headers and footers, and more.
* The 'empty-cells' property allows users to leave table cells empty
and still give them proper borders on the screen or on paper. A
data cell that is meant to be empty should not be filled with
white space or a non-breaking space just to achieve a visual
effect.
5.6.1 If you must use images as spacers
Provide text equivalents for all images, including invisible or
transparent images.
If content developers cannot use style sheets and must use invisible
or transparent images (e.g., with IMG) to lay out images on the page,
they should specify alt="" for them.
Deprecated example.
Authors should not use spaces for the value of "alt" to prevents the
words from running together when the image is not loaded:
my poem requires a big space
End example.
The following example illustrates the same idea, but uses OBJECT
instead of IMG to insert the image to provide more information about
the image:
Example.
End example.
In addition to providing a text equivalent, provide redundant textual
links. If the A element is used instead of AREA, the content developer
may describe the active regions and provide redundant links at the
same time:
Example.
End example.
Note that in the previous example, the MAP element is the content of
the OBJECT element so that the alternative links will only be
displayed if the image map (navbar1.gif) is not.
Note also that links have been separated by brackets ([]). This is to
prevent older screen readers from reading several adjacent links as a
single link as well as helps sighted users distinguish between links
visually.
Content developers should make sure they include printable characters
(such as brackets or a vertical bar (|)) surrounded by spaces between
adjacent links.
4.7.6 Server-side image maps
Checkpoints in this section: 1.2.
When a server-side image map must be used, content developers should
provide an alternative list of image map choices. There are three
techniques:
* Include the alternative links within the body of an OBJECT element
(refer to the previous example illustrating links in the OBJECT
element).
* If IMG is used to insert the image, provide an alternative list of
links after it and indicate the existence and location of the
alternative list (e.g., via that "alt" attribute).
Example.
End example.
The following deprecated example should be avoided since it inserts
IMG directly in a frame:
Deprecated example.
of what we mean.
here
In this next example, an image is used to force a graphic to appear in
a certain position:
End example.
5.7 Rules and borders
Rules and borders may convey the notion of "separation" to visually
enabled users but that meaning cannot be inferred out of a visual
context.
Use these CSS properties to specify border styles:
* 'border', 'border-width', 'border-style', 'border-color'.
* 'border-spacing' and 'border-collapse' for tables.
* 'outline, 'outline-color', 'outline-style', and 'outline-width'
for dynamic outlines.
Authors should use style sheets to create rules and borders.
Example.
In this example, the H1 element will have a top border that is 2px
thick, red, and separated from the content by 1em:
Chapter 8 - Auditory and Tactile Displays
End example.
If a rule (e.g., the HR element) is used to indicate structure, be
sure to indicate the structure in a non-visual way as well. (e.g., by
using structural markup).
Example.
In this example, the DIV element is used to create a navigation bar,
which includes a horizontal separator.
End example.
_________________________________________________________________
Checkpoint Map
This index lists each checkpoint and the sections in this document
where it is discussed. Furthermore, each guideline number links to its
definition in the guidelines document. Each checkpoint also links to
its definition in the guidelines document.
Guideline 1:
1.1 Provide a text equivalent for every non-text element (e.g., via
"alt", "longdesc", or in element content). This includes:
images, graphical representations of text (including symbols),
image map regions, animations (e.g., animated GIFs), applets
and programmatic objects, ascii art, frames, scripts, images
used as list bullets, spacers, graphical buttons, sounds
(played with or without user interaction), stand-alone audio
files, audio tracks of video, and video. [Priority 1]
(Checkpoint 1.1 in guidelines)
Refer to 3.2 Text equivalents and
4.7.1 Text equivalents for images
1.2 Provide redundant text links for each active region of a
server-side image map. [Priority 1] (Checkpoint 1.2 in
guidelines)
Refer to 3.2 Text equivalents and
4.7.6 Server-side image maps
1.3 Until user agents can automatically read aloud the text equivalent
of a visual track, provide an auditory description of the
important information of the visual track of a multimedia
presentation. [Priority 1] (Checkpoint 1.3 in guidelines)
Refer to 4.9.2 Visual information and motion
1.4 For any time-based multimedia presentation (e.g., a movie or
animation), synchronize equivalent alternatives (e.g., captions
or auditory descriptions of the visual track) with the
presentation. [Priority 1] (Checkpoint 1.4 in guidelines)
Refer to 4.8.3 Audio and Video produced by dynamic objects
1.5 Until user agents render text equivalents for client-side image
map links, provide redundant text links for each active region
of a client-side image map. [Priority 3] (Checkpoint 1.5 in
guidelines)
Refer to 3.2 Text equivalents and
4.7.5 Client-side image maps
Guideline 2:
2.1 Ensure that all information conveyed with color is also available
without color, for example from context or markup. [Priority 1]
(Checkpoint 2.1 in guidelines)
Refer to 5.5 Colors
2.2 Ensure that foreground and background color combinations provide
sufficient contrast when viewed by someone having color
deficits or when viewed on a black and white screen.
[Priority 2 for images, Priority 3 for text]. (Checkpoint 2.2
in guidelines)
Refer to 5.5 Colors
Guideline 3:
3.1 When an appropriate markup language exists, use markup rather than
images to convey information. [Priority 2] (Checkpoint 3.1 in
guidelines)
Refer to 4.3.4 Markup and style sheets rather than images: The
example of math
3.2 Create documents that validate to published formal grammars.
[Priority 2] (Checkpoint 3.2 in guidelines)
Refer to 4.1 Document structure and metadata
3.3 Use style sheets to control layout and presentation. [Priority 2]
(Checkpoint 3.3 in guidelines)
Refer to 3.2 Text equivalents and
4.3.1 Emphasis and
5 CSS Techniques
3.4 Use relative rather than absolute units in markup language
attribute values and style sheet property values. [Priority 2]
(Checkpoint 3.4 in guidelines)
Refer to 5.1 Guidelines for creating style sheets
3.5 Use header elements to convey document structure and use them
according to specification. [Priority 2] (Checkpoint 3.5 in
guidelines)
Refer to 4.1.2 Section headers
3.6 Mark up lists and list items properly. [Priority 2] (Checkpoint
3.6 in guidelines)
Refer to 4.4 Lists
3.7 Mark up quotations. Do not use quotation markup for formatting
effects such as indentation. [Priority 2] (Checkpoint 3.7 in
guidelines)
Refer to 4.3.3 Quotations
Guideline 4:
4.1 Clearly identify changes in the natural language of a document's
text and any text equivalents (e.g., captions). [Priority 1]
(Checkpoint 4.1 in guidelines)
Refer to 4.2 Language information
4.2 Specify the expansion of each abbreviation or acronym in a
document where it first occurs. [Priority 3] (Checkpoint 4.2 in
guidelines)
Refer to 4.3.2 Acronyms and abbreviations
4.3 Identify the primary natural language of a document. [Priority 3]
(Checkpoint 4.3 in guidelines)
Refer to 4.2 Language information
Guideline 5:
5.1 For data tables, identify row and column headers. [Priority 1]
(Checkpoint 5.1 in guidelines)
Refer to 4.5.1 Tables of data
5.2 For data tables that have two or more logical levels of row or
column headers, use markup to associate data cells and header
cells. [Priority 1] (Checkpoint 5.2 in guidelines)
Refer to 4.5.1 Tables of data
5.3 Do not use tables for layout unless the table makes sense when
linearized. Otherwise, if the table does not make sense,
provide an alternative equivalent (which may be a linearized
version). [Priority 2] (Checkpoint 5.3 in guidelines)
Refer to 4.5.2 Avoid tables for layout
5.4 If a table is used for layout, do not use any structural markup
for the purpose of visual formatting. [Priority 2] (Checkpoint
5.4 in guidelines)
Refer to 4.5.2 Avoid tables for layout
5.5 Provide summaries for tables. [Priority 3] (Checkpoint 5.5 in
guidelines)
Refer to 4.5.1 Tables of data
5.6 Provide abbreviations for header labels. [Priority 3] (Checkpoint
5.6 in guidelines)
Refer to 4.5.1 Tables of data
Guideline 6:
6.1 Organize documents so they may be read without style sheets. For
example, when an HTML document is rendered without associated
style sheets, it must still be possible to read the document.
[Priority 1] (Checkpoint 6.1 in guidelines)
Refer to 5.1 Guidelines for creating style sheets
6.2 Ensure that equivalents for dynamic content are updated when the
dynamic content changes. [Priority 1] (Checkpoint 6.2 in
guidelines)
Refer to 4.10.4 Always make the source of a frame an HTML
document
6.3 Ensure that pages are usable when scripts, applets, or other
programmatic objects are turned off or not supported. If this
is not possible, provide equivalent information on an
alternative accessible page. [Priority 1] (Checkpoint 6.3 in
guidelines)
Refer to 4.12.1 Graceful transformation of scripts
6.4 For scripts and applets, ensure that event handlers are input
device-independent. [Priority 2] (Checkpoint 6.4 in guidelines)
Refer to 4.12.2 Device-independent event handlers
6.5 Ensure that dynamic content is accessible or provide an
alternative presentation or page. [Priority 2] (Checkpoint 6.5
in guidelines)
Refer to 3.3 Alternative pages
Guideline 7:
7.1 Until user agents allow users to control flickering, avoid causing
the screen to flicker. [Priority 1] (Checkpoint 7.1 in
guidelines)
Refer to 3.9 Screen flicker
7.2 Until user agents allow users to control blinking, avoid causing
content to blink (i.e., change presentation at a regular rate,
such as turning on and off). [Priority 2] (Checkpoint 7.2 in
guidelines)
Refer to 5.3 Text style
7.3 Until user agents allow users to freeze moving content, avoid
movement in pages. [Priority 2] (Checkpoint 7.3 in guidelines)
Refer to 4.9.2 Visual information and motion
7.4 Until user agents provide the ability to stop the refresh, do not
create periodically auto-refreshing pages. [Priority 2]
(Checkpoint 7.4 in guidelines)
Refer to 3.8 Automatic page refresh
7.5 Until user agents provide the ability to stop auto-redirect, do
not use markup to redirect pages automatically. Instead,
configure the server to perform redirects. [Priority 2]
(Checkpoint 7.5 in guidelines)
Refer to 3.8 Automatic page refresh
Guideline 8:
8.1 Make programmatic elements such as scripts and applets directly
accessible or compatible with assistive technologies
[Priority 1 if functionality is important and not presented
elsewhere, otherwise Priority 2.] (Checkpoint 8.1 in
guidelines)
Refer to 4.8.2 Directly accessible applets and
4.8.3 Audio and Video produced by dynamic objects
Guideline 9:
9.1 Provide client-side image maps instead of server-side image maps
except where the regions cannot be defined with an available
geometric shape. [Priority 1] (Checkpoint 9.1 in guidelines)
Refer to 4.7.5 Client-side image maps
9.2 Ensure that any element that has its own interface can be operated
in a device-independent manner. [Priority 2] (Checkpoint 9.2 in
guidelines)
Refer to 3.4 Keyboard access
9.3 For scripts, specify logical event handlers rather than
device-dependent event handlers. [Priority 2] (Checkpoint 9.3
in guidelines)
Refer to 4.12.2 Device-independent event handlers
9.4 Create a logical tab order through links, form controls, and
objects. [Priority 3] (Checkpoint 9.4 in guidelines)
Refer to 4.11.1 Make controls keyboard accessible
9.5 Provide keyboard shortcuts to important links (including those in
client-side image maps), form controls, and groups of form
controls. [Priority 3] (Checkpoint 9.5 in guidelines)
Refer to 4.11.1 Make controls keyboard accessible
Guideline 10:
10.1 Until user agents allow users to turn off spawned windows, do not
cause pop-ups or other windows to appear and do not change the
current window without informing the user. [Priority 2]
(Checkpoint 10.1 in guidelines)
Refer to 4.10.5 Avoid opening a new window as the target of a
frame
10.2 Until user agents support explicit associations between labels
and form controls, for all form controls with implicitly
associated labels, ensure that the label is properly
positioned. [Priority 2] (Checkpoint 10.2 in guidelines)
Refer to 4.11.3 Label form controls explicitly
10.3 Until user agents (including assistive technologies) render
side-by-side text correctly, provide a linear text alternative
(on the current page or some other) for all tables that lay out
text in parallel, word-wrapped columns. [Priority 3]
(Checkpoint 10.3 in guidelines)
Refer to 4.5.3 Wrapped text in tables
10.4 Until user agents handle empty controls correctly, include
default, place-holding characters in edit boxes and text areas.
[Priority 3] (Checkpoint 10.4 in guidelines)
Refer to 4.11.7 Techniques for specific controls
10.5 Until user agents (including assistive technologies) render
adjacent links distinctly, include non-link, printable
characters (surrounded by spaces) between adjacent links.
[Priority 3] (Checkpoint 10.5 in guidelines)
Refer to 4.7.5 Client-side image maps
Guideline 11:
11.1 Use W3C technologies when they are available and appropriate for
a task and use the latest versions when supported. [Priority 2]
(Checkpoint 11.1 in guidelines)
Refer to 3.12 Browser Support
11.2 Avoid deprecated features of W3C technologies. [Priority 2]
(Checkpoint 11.2 in guidelines)
Refer to
11.3 Provide information so that users may receive documents according
to their preferences (e.g., language, content type, etc.)
[Priority 3] (Checkpoint 11.3 in guidelines)
Refer to 3.7 Content negotiation
11.4 If, after best efforts, you cannot create an accessible page,
provide a link to an alternative page that uses W3C
technologies, is accessible, has equivalent information (or
functionality), and is updated as often as the inaccessible
(original) page. [Priority 1] (Checkpoint 11.4 in guidelines)
Refer to 3.3 Alternative pages
Guideline 12:
12.1 Title each frame to facilitate frame identification and
navigation. [Priority 1] (Checkpoint 12.1 in guidelines)
Refer to 3.2 Text equivalents and
4.10.1 Title frames for easy orientation
12.2 Describe the purpose of frames and how frames relate to each
other if it is not obvious by frame titles alone. [Priority 2]
(Checkpoint 12.2 in guidelines)
Refer to 3.2 Text equivalents and
4.10.2 Text equivalents for frames
12.3 Divide large blocks of information into more manageable groups
where natural and appropriate. [Priority 2] (Checkpoint 12.3 in
guidelines)
Refer to 4.1.4 Structural grouping
12.4 Associate labels explicitly with their controls. [Priority 2]
(Checkpoint 12.4 in guidelines)
Refer to 4.11.3 Label form controls explicitly
Guideline 13:
13.1 Clearly identify the target of each link. [Priority 2]
(Checkpoint 13.1 in guidelines)
Refer to 4.6 Links
13.2 Provide metadata to add semantic information to pages and sites.
[Priority 2] (Checkpoint 13.2 in guidelines)
Refer to 3.5 Navigation and
4.1.1 Metadata and
4.1.3 Link metadata and navigation tools
13.3 Provide information about the general layout of a site (e.g., a
site map or table of contents). [Priority 2] (Checkpoint 13.3
in guidelines)
Refer to 3.5 Navigation
13.4 Use navigation mechanisms in a consistent manner. [Priority 2]
(Checkpoint 13.4 in guidelines)
Refer to 3.5 Navigation
13.5 Provide navigation bars to highlight and give access to the
navigation mechanism. [Priority 3] (Checkpoint 13.5 in
guidelines)
Refer to 3.5 Navigation
13.6 Group related links, identify the group (for user agents), and,
until user agents do so, provide a way to bypass the group.
[Priority 3] (Checkpoint 13.6 in guidelines)
Refer to 4.6 Links
13.7 If search functions are provided, enable different types of
searches for different skill levels and preferences.
[Priority 3] (Checkpoint 13.7 in guidelines)
Refer to 3.5 Navigation
13.8 Place distinguishing information at the beginning of headings,
paragraphs, lists, etc. [Priority 3] (Checkpoint 13.8 in
guidelines)
Refer to 3.6 Comprehension
13.9 Provide information about document collections (i.e., documents
comprising multiple pages.). [Priority 3] (Checkpoint 13.9 in
guidelines)
Refer to 3.10 Bundled documents
13.10 Provide a means to skip over multi-line ASCII art. [Priority 3]
(Checkpoint 13.10 in guidelines)
Refer to 3.2 Text equivalents and
4.7.3 Ascii art
Guideline 14:
14.1 Use the clearest and simplest language appropriate for a site's
content. [Priority 1] (Checkpoint 14.1 in guidelines)
Refer to 3.6 Comprehension
14.2 Supplement text with graphic or auditory presentations where they
will facilitate comprehension of the page. [Priority 3]
(Checkpoint 14.2 in guidelines)
Refer to 3.6 Comprehension
14.3 Create a style of presentation that is consistent across pages.
[Priority 3] (Checkpoint 14.3 in guidelines)
Refer to 3.5 Navigation
Index of HTML elements and attributes
Checkpoints in this section: 11.2.
Elements
Linear version of HTML 4.0 element index.
This index lists all elements in HTML 4.0. The first column of this
table links to the definition of the element in the HTML 4.0
specification ([HTML40]). Elements that are deprecated in HTML 4.0 are
followed by an asterisk (*). Elements that are obsolete in HTML 4.0 or
don't exist in a W3C specification of HTML (2.0, 3.2, 4.0) do not
appear in this table.
The second column indicates other W3C specifications for HTML that
included each element. The third column indicates the element's role.
The last column lists the sections in the current document where the
element is discussed. An entry of "N/A" means that the element is not
discussed in this document.
Element name Defined also in Role Techniques
A 2.0, 3.2 Structure 4.6 Links, 4.7.2 Invisible d-links, 4.7.5
Client-side image maps
ABBR Structure 4.3.2 Acronyms and abbreviations, 4.7.3 Ascii art
ACRONYM Structure 4.3.2 Acronyms and abbreviations
ADDRESS 2.0, 3.2 Metadata 4.1.1 Metadata
APPLET* 3.2 Replaced 4.8 Applets and other programmatic objects, 4.8.1
Text equivalents for applets and programmatic objects, 4.8.2 Directly
accessible applets
AREA 3.2 Structure 4.7.5 Client-side image maps
B 2.0, 3.2 Presentation 4.3.1 Emphasis
BASE 2.0, 3.2 Processing N/A
BASEFONT* 3.2 Presentation 5.2 Fonts
BDO Processing N/A
BIG 3.2 Presentation 5.2 Fonts
BLOCKQUOTE 2.0, 3.2 Structure 3.1 Structure vs. Presentation, 4.3.3
Quotations, 5.4 Text formatting
BODY 2.0, 3.2 Structure N/A
BR 2.0, 3.2 Presentation N/A
BUTTON Structure 4.11.6 Graphical buttons, 4.11.8 Backward
compatibility issues for forms
CAPTION 3.2 Structure 4.1.4 Structural grouping, 4.5.1 Tables of data
CENTER* 3.2 Presentation 5.6 Layout, positioning, layering, and
alignment
CITE 2.0, 3.2 Structure 4.3.5 Miscellaneous structural markup
CODE 2.0, 3.2 Structure 4.3.5 Miscellaneous structural markup
COL Structure 4.5.1 Tables of data
COLGROUP Structure 4.1.4 Structural grouping, 4.5.1 Tables of data
DD 2.0, 3.2 Structure 4.4.1 Use style sheets to change list bullets
DEL Metadata 4.3.5 Miscellaneous structural markup
DFN 3.2 Structure 4.3.5 Miscellaneous structural markup
DIR* 2.0, 3.2 Structure N/A
DIV 3.2 Structure 4.6.1 Grouping and bypassing links
DL 2.0, 3.2 Structure 4.1.4 Structural grouping, 4.4 Lists, 4.4.1 Use
style sheets to change list bullets
DT 2.0, 3.2 Structure 4.4.1 Use style sheets to change list bullets
EM 2.0, 3.2 Structure 4.3.1 Emphasis
FIELDSET Structure 4.1.4 Structural grouping, 4.11.2 Group form
controls
FONT* 3.2 Presentation 5.2 Fonts
FORM 2.0, 3.2 Structure 4.11 Forms
FRAME Replaced 4.6.1 Grouping and bypassing links, 4.10 Frames
FRAMESET Presentation 4.10 Frames, 4.10.2 Text equivalents for
frames
H1 2.0, 3.2 Structure 3.1 Structure vs. Presentation, 4.1.2 Section
headers, 4.1.4 Structural grouping
HEAD 2.0, 3.2 Structure N/A
HR 2.0, 3.2 Presentation 3.1 Structure vs. Presentation, 4.1.2 Section
headers
HTML 2.0, 3.2 Structure N/A
I 2.0, 3.2 Presentation 4.3.1 Emphasis
IFRAME Replaced 4.10 Frames
IMG 2.0, 3.2 Replaced 4.7.1 Text equivalents for images, 4.7.6
Server-side image maps, 4.10.4 Always make the source of a frame an
HTML document, 5.6.1 If you must use images as spacers
INPUT 2.0, 3.2 Structure 4.11.6 Graphical buttons, 4.11.8 Backward
compatibility issues for forms
INS Metadata 4.3.5 Miscellaneous structural markup
ISINDEX* 2.0, 3.2 Structure N/A
KBD 2.0, 3.2 Structure 4.3.5 Miscellaneous structural markup
LABEL Structure 4.11.3 Label form controls explicitly
LEGEND Structure 4.1.4 Structural grouping, 4.11.2 Group form
controls
LI 2.0, 3.2 Structure 4.4.1 Use style sheets to change list bullets
LINK 2.0, 3.2 Metadata 3.3 Alternative pages, 4.1.1 Metadata, 4.1.3
Link metadata and navigation tools, 5 CSS Techniques
MAP 3.2 Structure 4.7.4 Image maps
MENU* 2.0, 3.2 Structure N/A
META 2.0, 3.2 Metadata 3.8 Automatic page refresh, 4.1.1 Metadata
NOFRAMES Alternative 4.10.2 Text equivalents for frames
NOSCRIPT Alternative 4.12.3 Alternative presentation of scripts
OBJECT Replaced 3.2.1 Overview of technologies, 4.7.1 Text
equivalents for images, 4.7.5 Client-side image maps, 4.7.6
Server-side image maps, 4.8 Applets and other programmatic objects,
4.8.1 Text equivalents for applets and programmatic objects, 4.8.2
Directly accessible applets, 4.9.5 Embedding multimedia objects,
4.10.6 Alternatives to frames
OL 2.0, 3.2 Structure 4.1.4 Structural grouping, 4.4 Lists
OPTGROUP Structure 4.1.4 Structural grouping, 4.11.4 Group menu
options
OPTION 2.0, 3.2 Structure 4.11.4 Group menu options
P 2.0, 3.2 Structure 4.1.4 Structural grouping, 4.6.1 Grouping and
bypassing links
PARAM 3.2 Processing N/A
PRE 2.0, 3.2 Presentation 4.5.1 Tables of data
Q Structure 4.3.3 Quotations
S* Presentation N/A
SAMP 2.0, 3.2 Structure 4.3.5 Miscellaneous structural markup
SCRIPT 3.2 (DTD) Processing 4.12 Scripts
SELECT 2.0, 3.2 Structure 4.11.4 Group menu options
SMALL 3.2 Presentation 5.2 Fonts
SPAN Structure 4.6.1 Grouping and bypassing links
STRIKE* 3.2 Presentation N/A
STRONG 2.0, 3.2 Structure 4.3.1 Emphasis
STYLE 3.2 (DTD) Processing 5 CSS Techniques
SUB 3.2 Presentation N/A
SUP 3.2 Presentation N/A
TABLE 3.2 Structure 4.5 Tables
TBODY Structure 4.1.4 Structural grouping, 4.5.1 Tables of data
TD 3.2 Structure 4.5.1 Tables of data
TEXTAREA 2.0, 3.2 Structure 4.11.7 Techniques for specific controls
TFOOT Structure 4.1.4 Structural grouping, 4.5.1 Tables of data,
4.5.4 Backward compatibility issues for tables
TH 3.2 Structure 4.5.1 Tables of data
THEAD Structure 4.1.4 Structural grouping, 4.5.1 Tables of data
TITLE 2.0, 3.2 Metadata 4.1.1 Metadata
TR 3.2 Structure N/A
TT 2.0, 3.2 Presentation N/A
U* 3.2 Presentation N/A
UL 2.0, 3.2 Structure 4.1.4 Structural grouping, 4.4 Lists
VAR 2.0, 3.2 Structure 4.3.5 Miscellaneous structural markup
Attributes
Linear version of HTML 4.0 attribute index.
This index lists some attributes in HTML 4.0 that affect accessibility
and what elements they apply to. The first column of this table links
to the definition of the attribute in the HTML 4.0 specification
([HTML40]). Attributes and elements that are deprecated in HTML 4.0
([HTML40]) are followed by an asterisk (*). Attributes and elements
that are obsolete in HTML 4.0 or don't exist in a W3C specification of
HTML (2.0, 3.2, 4.0) do not appear in this table. Attributes that
apply to most elements of HTML 4.0 are indicated as such; please
consult the HTML 4.0 specification for the exact list of elements with
this attribute.
The second column indicates other W3C specifications for HTML that
included each attribute. The third column indicates the elements that
take each attribute. The fourth column indicates the attribute's role.
The last column lists the sections in the current document where the
attribute is discussed. An entry of "N/A" means that the attribute is
not discussed in this document.
Attribute name Applies to elements Role Techniques
abbr TD, TH Alternative 4.5.1 Tables of data
accesskey A, AREA, BUTTON, INPUT, LABEL, LEGEND, TEXTAREA User
Interface 4.11.5 Keyboard access to forms
alt APPLET, AREA, IMG, INPUT Alternative 3.2.1 Overview of
technologies, 4.7.1 Text equivalents for images, 4.7.2 Invisible
d-links, 4.7.5 Client-side image maps, 4.7.6 Server-side image maps,
4.8.1 Text equivalents for applets and programmatic objects, 5.6.1 If
you must use images as spacers
axis TD, TH Structure 4.5.1 Tables of data
class Most elements Structure 4.6.1 Grouping and bypassing links
dir Most elements Processing 4.5.1 Tables of data
for LABEL Structure 4.11.3 Label form controls explicitly
headers TD, TH Structure 4.5.1 Tables of data, 4.5.1 Tables of data
hreflang A, LINK Metadata 3.7 Content negotiation
id Most elements Structure 4.6.1 Grouping and bypassing links
label OPTION Alternative 4.11.4 Group menu options
lang Most elements Metadata 4.2 Language information
longdesc IMG, FRAME, IFRAME Alternative 3.2.1 Overview of
technologies, 4.7.1 Text equivalents for images
scope TD, TH Structure 4.5.1 Tables of data
style Most elements Processing 5 CSS Techniques
summary TABLE Alternative 4.5.1 Tables of data
tabindex A, AREA, BUTTON, INPUT, OBJECT, SELECT, TEXTAREA User
Interface 4.6.1 Grouping and bypassing links, 4.6.2 Keyboard access,
4.11.5 Keyboard access to forms
title Most elements Metadata 3.2.2 Backward Compatibility, 4.1.1
Metadata, 4.3.2 Acronyms and abbreviations, 4.6 Links, 4.7.3 Ascii art
usemap IMG, INPUT, OBJECT Processing 4.7.4 Image maps
The following is the list of HTML 4.0 attributes not directly related
to accessibility. Content developers should use style sheets instead
of presentation attributes. For even handler attributes, please refer
to the section on device-independent event handlers for more detail.
Other structural attributes:
start*, value*, rowspan, colspan, span
Other presentation attributes:
align*, valign*, clear*, nowrap*, char, charoff, hspace*,
vspace*, cellpadding, cellspacing, compact*, face*, size*,
background*, bgcolor*, color*, text*, link*, alink*, vlink*,
border, noshade*, rules, size (deprecated according to
element), marginheight, marginwidth, frame, frameborder, rows,
cols
Other processing instruction attributes:
ismap, coords, shape
Other user interface attributes:
target, scrolling, noresize
Other metadata attributes:
type, cite, datetime
Event handler attributes:
onblur, onchange, onclick, ondblclick, onfocus, onkeydown,
onkeypress, onkeyup, onload, onload, onmousedown, onmousemove,
onmouseout, onmouseover, onmouseup, onreset, onselect,
onsubmit, onunload
_________________________________________________________________
Acknowledgments
Web Content Guidelines Working Group Co-Chairs:
Chuck Letourneau, Starling Access Services
Gregg Vanderheiden, Trace Research and Development
W3C Team contacts:
Judy Brewer and Daniel Dardailler
We wish to thank the following people who have contributed their time
and valuable comments to shaping these guidelines:
Harvey Bingham, Kevin Carey, Chetz Colwell, Neal Ewers, Geoff
Freed, Al Gilman, Larry Goldberg, Jon Gunderson, Eric Hansen,
Phill Jenkins, Leonard Kasday, George Kerscher, Marja-Riitta
Koivunen, Josh Krieger, Scott Luebking, William Loughborough,
Murray Maloney, Charles McCathieNevile, MegaZone (Livingston
Enterprises), Masafumi Nakane, Mark Novak, Charles Oppermann,
Mike Paciello, David Pawson, Michael Pieper, Greg Rosmaita,
Liam Quinn, Dave Raggett, T.V. Raman, Robert Savellis, Jutta
Treviranus, Steve Tyler, Jaap van Lelieveld, and Jason White
The original draft of this document is based on "The Unified Web Site
Accessibility Guidelines" ([UWSAG]) compiled by the Trace R & D Center
at the University of Wisconsin. That document includes a list of
additional contributors.
Reference specifications
For 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 Specification", V.
Apparao, S. Byrne, M. Champion, S. Isaacs, I. Jacobs, A. Le
Hors, G. Nicol, J. Robie, R. Sutor, C. Wilson, and L. Wood,
eds., 1 October 1998. The DOM Level 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 available 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 checkpoints defined in "Web
Content Accessibility Guidelines 1.0". The latest draft of the
techniques is available at:
http://www.w3.org/TR/WAI-WEBCONTENT-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 accessible 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 document. 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
designing accessible user agents is available at:
http://www.w3.org/TR/WAI-USERAGENT/
[WCAG-ICONS]
Information about conformance icons for this document and how
to use them is available at
http://www.w3.org/WAI/WCAG1-Conformance.html
[UWSAG]
"The Unified Web Site Accessibility Guidelines", G.
Vanderheiden, W. Chisholm, eds. The Unified Web Site Guidelines
were compiled by the Trace R & D Center at the University of
Wisconsin under funding from the National Institute on
Disability and Rehabilitation Research (NIDRR), U.S. Dept. of
Education. This document is available at:
http://www.tracecenter.org/docs/html_guidelines/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
Recommendation 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
Services
Note. W3C cannot maintain stability for any of the following
references outside of its control. These references are included for
convenience.
[ASTER]
For information about ASTER, an "Audio System For Technical
Readings", consult T. V. Raman's home page.
[BOBBY]
Bobby is an automatic accessibility validation tool developed
by Cast.
[BROWSERCAPS]
BrowserCaps.
[CSSVAL]
The W3C CSS Validation Service.
[DVS]
DVS Descriptive Video Services.
[HACKER]
Hacker, Diana. (1993). A Pocket Style Manual. St. Martin's
Press, Inc. 175 Fifth Avenue, New York, NY 10010.
[HOMEPAGEREADER]
IBM's Home Page Reader.
[HTMLVAL]
The W3C HTML Validation Service.
[HYPERMEDIA]
IBM's techexplorer Hypermedia Browser.
[IBMJAVA]
IBM Guidelines for Writing Accessible Applications Using 100%
Pure Java are available from IBM Special Needs Systems.
[JAVAACCESS]
Information about Java Accessibility and Usability is available
from the Trace R&D Center.
[JAWS]
Henter-Joyce's Jaws screen reader.
[LIGHTHOUSE]
The Lighthouse provides information about accessible colors and
contrasts.
[LYNX]
Lynx is a text-only browser.
[LYNXME]
Lynx-me is a Lynx emulator.
[LYNXVIEW]
Lynx Viewer is a Lynx emulator.
[MACROMEDIA]
Flash OBJECT and EMBED Tag Syntax from Macromedia.
[NCAM]
The National Center for Accessible Media includes information
about captioning and audio description on the Web.
[PWWEBSPEAK]
The Productivity Works' pwWebSpeak.
[SPOOL]
Spool, J.M., Sconlong, T., Schroeder, W., Snyder, C., DeAngelo,
T. (1997). Web Site Usability: A Designer's Guide User
Interface Engineering, 800 Turnpike St, Suite 101, North
Andover, MA 01845.
[TECHHEAD]
Tech Head provides some information about the Fog index
described in [SPOOL].
[TRACE]
The Trace Research & Development Center. Consult this site for
a variet of information about accessibility, including a
scrolling Java applet that may be frozen by the user.
[WAI-ER]
The WAI Evaluation and Repair Working Group
[WALSH]
Walsh, Norman. (1997). "A Guide to XML." In "XML: Principles,
Tools, and Techniques." Dan Connolly, Ed. O'Reilly &
Associates, 101 Morris St, Sebastopol, CA 95472. pp 97-107.
[WEBREVIEW]
webreview.com style sheet browser compatibility charts.
[WINVISION]
Artic's WinVision.
_________________________________________________________________
[contents] [checkpoint map] [html index]