wai-gl-techniques-19980825
W3C Working Draft -25 August 1998
This document is a list of techniques that implement the guidelines described in "WAI Guidelines: Page Authoring". This document includes primarily techniques that HTML authors may use to implement the guidelines, but also refers to some CSS techniques as well.
This document is part of a series of accessibility documents published by the Web Accessibility Initiative.
This is a W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". This is work in progress and does not imply endorsement by, or the consensus of, either W3C or members of the WAI GL Working Group.
This document has been produced as part of the W3C WAI Activity, and is intended as a draft of a Proposed Recommendation for authoring accessible Web pages. The goal of the WAI-GL working group is discussed in our charter.
Please send detailed comments on this document to w3c-wai-gl@w3.org. Public comments about the WAI author guidelines can also be sent to this mailing list.
The following sections discuss some accessibility issues that arise when one creates HTML documents.
Distinguishing the structure of a document from how the content is presented offers a number of advantages, including improved accessibility, manageability, and scalability. The next two sections identify (by theme) precisely those elements and attributes considered structural (and some of their uses) and those that are considered to control presentation. The section on style and style sheets discusses how to use CSS to accomplish the same tasks as the presentation elements and attributes.
Elements and attributes that are deprecated in HTML 4.0 are marked up in this document and followed by an asterisk (*).
Note. Not all attributes are listed in this section. Only those deemed pertinent to accessibility have been listed.
Text is almost always accessible as it may be spoken by screen readers, presented by non-visual browsers and braille readers, etc. HTML 4.0 allows authors to provide text descriptions of visual or audio content in a number of ways:
Here is a summary of attributes used for alt-text and long descriptions and the elements they apply to (by version of HTML):
Not every user agent supports these attributes. When required to design documents for a version of HTML known not to support one of these attributes, authors should implement alt-text or descriptions in other ways. Methods include:
Each of the HTML topics below describes prioritized scenarios for alt-text and descriptions.
Some image formats allow internal text in the data file along with the image information. If an image format supports such text (e.g., PNG) authors may also supply brief descriptions there as well.
In cases where it is not possible to make part of a page accessible, you must allow users to navigate to a separate page that is accessible and that is maintained with the same frequency as the "main" page. There are several techniques for linking to an accessible alternate page:
Example.
<HEAD>
<TITLE>Welcome to the Virtual Mall!</TITLE>
<LINK title="Text-only version"
rel="alternate"
href="text_only.html"
media="aural, braille, tty">
</HEAD>
Authors should always ensure that users may interact with a page with devices other than a pointing device (mouse). HTML includes two techniques for specifying keyboard access to form controls and links:
Here is a summary of attributes used for keyboard access and long descriptions and the elements they apply to (by version of HTML):
In the following example, if the accesskey is activated, "doc.html" is retrieved by the browser:
Example.
<A accesskey="C" href="doc.html" hreflang="en"
title="XYZ company home page">
XYZ company home page</A>
The next example assigns "U" as the access key. Typing "U" gives focus to the label, which gives focus to the control, so that the user can input text.
Example.
<FORM action="submit" method="post">
<LABEL for="user" accesskey="U">name</LABEL>
<INPUT type="text" name="user">
</FORM>
In the next example, we specify a tabbing order among elements (in order, "field1", "field2", "submit"):
Example.
<INPUT tabindex="1" type="text" name="field1"> <INPUT tabindex="2" type="text" name="field2"> <INPUT tabindex="3" type="submit" name="submit">
The following sections document HTML accessibility features and techniques, organized by topic (and mirroring the organization of the HTML 4.0 specification).
Use structural markup wherever possible, and use it as intended by the authors of the HTML 4.0 Recommendation. Structural elements enforce 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.
Metadata is information about data. This information can provide important orientation information to users. HTML elements that provide useful information about a document include:
Note. Automatic refresh is valid behavior, supported by some user agents, but this behavior is not required by the HTML 4.0 specification.
Since some users skim through a document by navigating its headings, it is important to increment heading levels correctly (H1 followed by H2, rather than H1 followed by H3). Headings should not be used for other purposes (such as formatting text in a larger font size) since this may disorient users; use style sheets for text formatting.
If you use a number of different languages on a page, make sure that any changes in language are clearly identified by using the "lang" attribute:
Example.
<P>And with a certain <SPAN lang="fr">je ne sais quoi</SPAN>, she entered both the room, and his life, forever. <Q>My name is Natasha,</Q> she said. <Q lang="it">Piacere,</Q> he replied in impeccable Italian, locking the door.
The proper HTML elements should be used to mark up emphasis: EM and STRONG. While style sheets, elements, and attributes may indicate emphasis to visually enabled users, they may not to other users. 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.)
Mark up abbreviations and acronyms with ABBR and ACRONYM and use "title" to indicate the expansion:
Example.
<Welcome to the <ACRONYM title="World Wide Web">WWW</ACRONYM>!
Mark up quotations with the Q (HTML 4.0) and BLOCKQUOTE (HTML 3.2 and HTML 4.0) elements. Do not use them for formatting effects such as indentation.
To change the "bullet" style of unordered list items, use style sheets. This way, if images are not loaded, the browser will draw a default bullet.
Example.
<STYLE ...>
UL { list-style: url(star.gif) }
</STYLE>
...
<UL>
<LI>Audrey
<LI>Laurie
<LI>Alice
</UL>
Avoid using images as bullets in definition lists. However, if this method is used, be sure to provide alt-text for the images.
Deprecated example.
<DL> <DD><IMG src="star.gif" alt="Item">Audrey <DD><IMG src="star.gif" alt="Item">Laurie <DD><IMG src="star.gif" alt="Item">Alice </DL>
Authors should avoid list styles where bullets provide additional (visual) information. However, if this is done, be sure to provide alt-text describing meaning of the bullet:
Deprecated example.
<DL> <DD><IMG src="red.gif" alt="New:">Roth IRA</DD> <DD><IMG src="yellow.gif" alt="Old:">401(k)</DD> </DL>
Here is a better way to change list bullet styles (using style sheets). To further ensure that users understand differences between list items indicated visually, authors should provide a label before or after the list item phrase:
Example.
<STYLE type="text/css" ...>
.newtxt { font-weight: bold;
color: red;
background-color: yellow }
.newbullet { list-style : url(yellow.gif) }
</STYLE>
...
<UL>
<LI class="newbullet">Roth IRA <SPAN class="newtext">New</SPAN>
<LI 401(k)
</UL>
Users may make tables more accessible in a number of ways:
Most of the above elements and attributes are only available in HTML 4.0.
This markup will allow accessible browsers and other user agents to restructure tables for non-visual media.
For information about table headers, see the table header algorithm and discussion in the HTML 4.0 Recommendation.
The following example shows how to associate data cells with their corresponding headers by means of the "headers" attribute. The "headers" attribute specifies a list of header cells (row and column labels) associated with the current data cell. This requires each header cell to have an "id" attribute.
<TABLE border="border"
summary="This table charts the number of
cups of coffee consumed by each senator,
the type of coffee (decaf or regular),
and whether taken with sugar.">
<CAPTION>Cups of coffee consumed by each senator</CAPTION>
<TR>
<TH id="t1">Name</TH>
<TH id="t2">Cups</TH>
<TH id="t3" abbr="Type">Type of Coffee</TH>
<TH id="t4">Sugar?</TH>
<TR>
<TD headers="t1">T. Sexton</TD>
<TD headers="t2">10</TD>
<TD headers="t3">Espresso</TD>
<TD headers="t4">No</TD>
<TR>
<TD headers="t1">J. Dinnen</TD>
<TD headers="t2">5</TD>
<TD headers="t3">Decaf</TD>
<TD headers="t4">Yes</TD>
</TABLE>
A speech synthesizer might render this tables as follows:
Caption: Cups of coffee consumed by each senator
Summary: This table charts the number of cups of coffee
consumed by each senator, the type of coffee
(decaf or regular), and whether taken with sugar.
Name: T. Sexton, Cups: 10, Type: Espresso, Sugar: No
Name: J. Dinnen, Cups: 5, Type: Decaf, Sugar: Yes
The next example associates the same header and data cells as before, but this time uses the "scope" attribute rather than "headers." "Scope" must have one of the following values: row, col, rowgroup or colgroup. Scope specifies the set of data cells to be associated with the current header cell. This method is particularly useful for simple tables. It should be noted that the spoken rendering of this table would be identical to that of the previous example. A choice between the "headers" and "scope" attributes is dependent on the complexity of the table. It does not affect the output so long as the relationships between header and data cells are made clear in the markup.
Example.
<TABLE border="border"
summary="This table charts ...">
<CAPTION>Cups of coffee consumed by each senator</CAPTION>
<TR>
<TH scope="col">Name</TH>
<TH scope="col">Cups</TH>
<TH scope="col" abbr="Type">Type of Coffee</TH>
<TH scope="col">Sugar?</TH>
<TR>
<TD>T. Sexton</TD> <TD>10</TD>
<TD>Espresso</TD> <TD>No</TD>
<TR>
<TD>J. Dinnen</TD> <TD>5</TD>
<TD>Decaf</TD> <TD>Yes</TD>
</TABLE>
The following example shows how to create categories within a table using the "axis" attribute.
Example.
<TABLE border="border">
<CAPTION>Travel Expense Report</CAPTION>
<TR>
<TH></TH>
<TH id="a2" axis="expenses">Meals
<TH id="a3" axis="expenses">Hotels
<TH id="a4" axis="expenses">Transport
<TD>subtotals</TD>
<TR>
<TH id="a6" axis="location">San Jose
<TH> <TH> <TH> <TD>
<TR>
<TD id="a7" axis="date">25-Aug-97
<TD headers="a6 a7 a2">37.74
<TD headers="a6 a7 a3">112.00
<TD headers="a6 a7 a4">45.00
<TD>
<TR>
<TD id="a8" axis="date">26-Aug-97
<TD headers="a6 a8 a2">27.28
<TD headers="a6 a8 a3">112.00
<TD headers="a6 a8 a4">45.00
<TD>
<TR>
<TD>subtotals
<TD>65.02
<TD>224.00
<TD>90.00
<TD>379.02
<TR>
<TH id="a10" axis="location">Seattle
<TH> <TH> <TH> <TD>
<TR>
<TD id="a11" axis="date">27-Aug-97
<TD headers="a10 a11 a2">96.25
<TD headers="a10 a11 a3">109.00
<TD headers="a10 a11 a4">36.00
<TD>
<TR>
<TD id="a12" axis="date">28-Aug-97
<TD headers="a10 a12 a2">35.00
<TD headers="a10 a12 a3">109.00
<TD headers="a10 a12 a4">36.00
<TD>
<TR>
<TD>subtotals
<TD>131.25
<TD>218.00
<TD>72.00
<TD>421.25
<TR>
<TH>Totals
<TD>196.27
<TD>442.00
<TD>162.00
<TD>800.27
</TABLE>
Users who are blind often jump from link to link when skimming a page or looking for information. When they do this, only the text of the link ("link text") is read. Therefore, it is important that link text make sense when read without surrounding text. For example, authors should not use "click here" as link text several times on the same page; this requires a user browsing the page with a screen reader to step through each link and read the surrounding text to determine the purpose of the link. Instead, link text should carry sufficient information, as in "download this document in ASCII text," "view the full version in HTML," or "for the text version select this link."
When an image is used as the content of a link, specify alt-text for the image that makes sense in context (i.e., if you were to specify text for the link content, what would it be?).
Example.
<A href="routes.html">
<IMG src="topo.html"
alt="Current routes at Boulders Climbing Gym">
</A>
Images may be inserted by two elements in HTML:
Images include those that carry out simple animations (e.g., a "gif" image).
When using IMG, specify alt-text with the "alt" attribute.
Example
<IMG src="magnifyingglass.gif" alt="Search">
When using OBJECT, specify alt-text either with the "title" attribute:
Example
<OBJECT classid="Duke.class" title="Java applet: Duke waving."
width="50" height="50">
</OBJECT>
or in the body of the OBJECT element:
Example
<OBJECT data="magnifyingglass.gif" type="image/gif">
Search
</OBJECT>
When using IMG, specify a brief description of the image with the "title" attribute:
Example
<IMG src="bell.gif" alt="Return to home page"
"Cow logo shaped like a bell">
When using IMG, specify a long description of the image with the "longdesc" attribute:
Example.
<IMG src="97sales.gif" alt="Sales for 1997"
longdesc="sales97.html>
In sales97.html:
A chart showing how sales in 1997 progressed. The chart is a pie-chart showing percentage increases in sales by month.
For browsers that don't support "longdesc", provide a description link as well next to the graphic:
Example.
<IMG src="97sales.gif" alt="Sales for 1997"> <A href="sales.html" title="Description of 1997 sales figures">[D]</A>
When using OBJECT, provide a long description in the body of the element:
Example.
<OBJECT data="97sales.gif" type="image/gif">
Sales in 1997 were down subsequent to our
anticipated blah blah blah...
</OBJECT>
Authors should avoid ascii art (character illustrations) and use real images instead since it is easier to supply alt-text and long descriptions for real images. However, if ascii art must be used, mark it up as such:
Example.
<SPAN alt="smile" title="smiley in ascii art">:-)</SPAN>
Another way to replace ascii art is to use human language substitutes. For example, <wink> might substitute for the emoticon <SPAN alt="wink" title="wink smiley">;-)</SPAN>, the word "therefore" could replace arrows consisting of dashes and greater than signs (e.g., -->), and the word "great" for the uncommon abbreviation "gr8".
Authors must ensure that image map information is available in textual form (links) and may be navigated with the keyboard.
Image maps are created with the MAP element (available in HTML 4.0 and 3.2). The active regions of an image map are defined within the MAP element and may be created with two elements:
HTML allows two types of image maps: client-side (the user's browser processes a URL) and server-side (the server processes click coordinates). In general, authors should avoid server-side image maps because they require a specific input device (a mouse).
Users should provide alternate text for image maps since they convey visual information.
If AREA is used, use the "alt" attribute:
Example.
<IMG src="welcome.gif" alt="Image map of areas in the library"
usemap="#map1">
<MAP name="map1">
<AREA shape="rect" coords="0,0,30,30"
href="reference.html" alt="Reference">
<AREA shape="rect" coords="34,34,100,100"
href="media.html" alt="Audio visual lab">
</MAP>
The same idea, but use OBJECT instead of IMG to insert the image to provide more information about the image:
Example.
<OBJECT data="welcome.gif" type="image/gif" usemap="#map1">
There are several areas in the library including
the <A href="reference.html">Reference</a> section and the
<A href="media.html">Audio Visual Lab</A>.
</OBJECT>
<MAP name="map1">
<AREA shape="rect" coords="0,0,30,30"
href="reference.html" alt="Reference">
<AREA shape="rect" coords="34,34,100,100"
href="media.html" alt="Audio visual lab">
</MAP>
If the A element is used instead of AREA, the author may describe the active regions and provide descriptive link text at the same time:
<OBJECT data="navbar1.gif" type="image/gif" usemap="#map1">
<MAP name="map1">
<P>Navigate the site.
<A href="guide.html" shape="rect"
coords="0,0,118,28">[Access Guide]</A>
<A href="shortcut.html" shape="rect"
coords="118,0,184,28">[Go]</A>
<A href="search.html" shape="circ"
coords="184.200,60">[Search]</A>
<A href="top10.html" shape="poly"
coords="276,0,373,28,50,50">[Top Ten]</A>
</MAP>
</OBJECT>
Note in the previous example that 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 screen readers from reading several adjacent links as a single link. Authors should make sure they include printable characters (such as brackets or a vertical bar (|)) surrounded by spaces between adjacent links.
See the section on brief descriptions for images.
See the section on long descriptions for images.
When a server-side image map must be used, authors should provide an alternative list of image map choices. There are three techniques:
Example.
Under construction
Authors should avoid using a button with an image on it as a server side image map. Use separate buttons or images instead.
Applets may be inserted by two elements in HTML:
If an applet performs an important function other than presenting information (e.g., gathering information for a database), authors should provide alternative mechanisms for performing the same function. Alternative information-gathering mechanisms such as a user-input form, e-mail address, phone or fax number should be provided within the content of whichever element is used to embed the applet.
If an 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. [@@link to resource.]
If OBJECT is used, provide alt-text as the content of the element:
Example.
<OBJECT classid="java:Press.class" width="500" height="500"
title="Java applet: how temperature affects pressure">
As temperature increases, the molecules in the balloon...
</OBJECT>
A more complex example takes advantage of the fact the OBJECT elements may be embedded to provide for alternative representations of information:
Example.
<OBJECT title="How temperature affects pressure"
classid="java:Press.class" width="500" height="500">
<OBJECT data="Pressure.mpeg" type="video/mpeg">
<OBJECT data="Pressure.gif" type="image/gif">
As temperature increases, the molecules in the balloon...
</OBJECT>
</OBJECT>
</OBJECT>
If APPLET is used, provide alt-text with the "alt" attribute and content in the APPLET element. This enables them to fail gracefully for those user agents that only support one of the two mechanisms ("alt" or content).
Example.
<APPLET code="Press.class" width="500" height="500"
alt="Java applet: how temperature affects pressure">
As temperature increases, the molecules in the balloon...
</APPLET>
Authors should avoid creating movement in pages. However, if necessary to include an applets that involves movement or updates, authors should provide a mechanism for freezing this movement. In an example of movement control created by Mark Novak, if the user presses the escape key while the Java marquee has focus, the text will be displayed statically. Authors should use animated gifs to create movement that may be suspended by the browser for people that have trouble with it.
See also the section on text style for controlling blinking.
Style sheets should be used to control layout and presentation wherever possible in a document. CSS1 and CSS2 allow authors to duplicate almost every HTML 4.0 presentation feature and offer more power with less cost. However, until most users have browsers that support style sheets, not every presentation idiom may be expressed satisfactorily with style sheets. Until support is adequate:
@@examples?
When these techniques are used, authors must furnish alternative pages as well to ensure accessibility.
The following sections explain how to use style sheets once a majority of users use browsers that support CSS.
Authors should use style sheets for text formatting rather than converting text to images. For example, stylized text on a colored background can be created with style sheets instead of as an image. This provides flexibility for people to view the text in a form that is most readable to them including magnified, in a particular color combination such as white on black, or in a particular font.
Authors should use style sheets instead of deprecated presentation elements and presentation attributes that control visual presentation.
Authors should avoid creating movement and blinking in a page where possible; blinking may cause seizures in some users and is annoying to many other users. They should also provide a mechanism for freezing movement. If style sheets are used to create an effect (e.g., 'text-decoration: blink'), users may cancel the effect through style sheets as well.
Note. Do not use the BLINK and MARQUEE elements. These elements are not part of any W3C specification for HTML (i.e., they are non-standard elements).
Use the CSS 'text-indent' property to indent text. Do not use the BLOCKQUOTE or any other structural element to indent text.
Authors should achieve spacing effects with the CSS 'word-spacing' property rather than by putting actual spaces between letters.
In general, authors should use style sheets to specify special effects for text (colors, fonts, transformations, shadows, etc.) When this is not possible, authors may use a picture of stylized or colorful text. In this case, the alt-text for the image must be the same text represented by the image.
Example.
<P>This is an
<IMG src="BigRedExample.gif"
alt="Example"> of what we mean.
</P>
This is true of Drop Caps (large first letter of a paragraph) as well. However, we recommend using style sheets to create the effect, as the following example illustrates.
Note.
<STYLE ...>
.dropcap { font-size : 120%; font-family : Helvetica }
</STYLE>
...
<SPAN class="dropcap">O</SPAN>nce upon a time...
Use the many CSS properties to control font characteristics: 'font-family', 'font-size', 'font-size-adjust', 'font-stretch', 'font-style', 'font-variant', and 'font-weight'.
Use style sheets to specify colors:
Authors must ensure that text and graphics are perceivable and understandable when viewed without color. To do so, provide other semantic clues in content or markup. For example, in this document, examples appear in a different color than the rest of the text. However, that is not enough to identify them as examples, so we precede each one with the word "Example." or "Deprecated example."
Don't use color to convey information, unless the information is also clear from the markup and/or text. To text whether this is the case, examine your page with a monochrome monitor or colors turned off.
Authors must ensure that foreground and background color combinations provide sufficient contrast when viewed by someone with color blindness (or on a black and white screen).
[@@link to http://www.lighthouse.org]
Layout, positioning, and alignment should be done through style sheets (notably by using CSS floats and absolute positioning).
Do not use PRE to create a tabular layout of text; use real tables instead (as they may be marked up helpfully).
If authors cannot use style sheets and must use invisible or transparent images to lay out images on the page, they must supply "null" (alt="") or "white space" (alt=" ") alt-text, whichever the context requires. Note that the HTML 4.0 specification recommends that attribute values not contain leading or trailing spaces. It states, "User agents may ignore leading and trailing white space in CDATA attributes values (e.g., "myval " may be interpreted as "myval")." Therefore, empty alt-text (alt=" ") might be ignored.
Deprecated example.
In this example, an image is used to create a carefully defined space between words or graphics. "White space" alt-text is used to prevent the words from running together when the image is not loaded:
my poem requires a big space<IMG src="10pttab.gif" alt=" ">here
In this next example, an image is used to force a graphic to appear in a certain position:
<IMG src="spacer.gif" alt=""> <IMG src="colorfulwheel.gif" alt="The wheel of fortune">
Rules and borders may convey the notion of "separation" to visually enabled users but that meaning cannot be inferred out of a visual context.
While authors may use HR to create a horizontal rule, they should do so in a way that also conveys the structure in a non-visual way (e.g., by using DIV in conjunction with the "class" attribute).
Example.
<DIV class="navigation-bar">
<HR title="navigation-bar">
<A rel="Next" href="next.html">[Next page]</A>
<A rel="Previous" href="previous.html">[Prevous page]</A>
<A rel="First" href="first.html">[First page]</A>
</DIV>
When using graphics (e.g., horizontal rules) as section separators, authors should provide a brief description of what the graphic represents to the visually enabled user via the "title" attribute. Hence, in the previous example, we specified title="navigation-bar".
Example.
In this example, a red line is used to separate Chapter 7 from Chapter 8:
<IMG src="redline.gif" title="End of Chapter 7 - Visual Displays"> <H1>Chapter 8 - Auditory and Tactile Displays</H1>
We recommend using style sheets to accomplish such styling of the line:
<STYLE type="text/css">
HR.redline { color : red }
</STYLE>
<IMG class="redline" title="End of Chapter 7 - Visual Displays">
<H1>Chapter 8 - Auditory and Tactile Displays</H1>
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.
For reasons of orientation, frames should all be named (with the "name" attribute) even if they are not potential targets for updated content.
Example.
<FRAMESET cols="10%,90%"
title="Our library of electronic documents">
<FRAME src="nav.html" name="navbar" title="Navigation bar">
<FRAME src="doc.html" name="doc" title="Documents">
<NOFRAMES>
<A href="lib.html" title="library link">
Select to go to the electronic library</A>
</NOFRAMES>
</FRAMESET>
Authors should provide a brief description of each frame with the "title" attribute.
Authors should provide a long description of a frame (where needed) by using either "longdesc" or "d-links" in a NOFRAMES element.
Example. Under construction
Authors must ensure that pages are readable and usable without frames. This may be done by providing a NOFRAMES alternative at the end of each FRAMESET.
Example.
In this example, if the user reads "top.html":
<!-- This is top.html -->
<HTML>
<HEAD>...</HEAD>
<FRAMESET cols="50%, 50%" title="Our big document">
<FRAME src="main.html" title="Where it's all at">
<FRAME src="table_of_contents.html" title="Table of Contents">
<NOFRAMES>
Here's the <A href="main.html">non-frames version.</A>
</NOFRAMES>
</FRAMESET>
</HTML>
and the user agent is not displaying frames, the user will have access (via a link) to a non-frames version of the same information. Furthermore, we can build main.html so that if frames are being supported, main.html does not show a table of contents (since top.html does), and if frames aren't being supported, it does not:
<!-- This is main.html -->
<HTML>
<HEAD>...</HEAD>
<BODY>
<NOFRAMES>
...the table of contents when frames not supported...
</NOFRAMES>
...the rest of the document, always available...
</BODY>
</HTML>
Authors must provide descriptions of frames so that their contents and the relationships between frames make sense. Note that as the contents of a frame change, so must change any description. This is not possible if an IMG is inserted directly into a frame, as in this deprecated example:
Deprecated example.
<FRAME name="badframe"
src="apples.gif" title="Apples">
Note that if, for example, a link causes a new image to be inserted into the frame:
Visit a beautiful grove of <A target="badframe" src="oranges.gif" title="Oranges">oranges</A>
the initial title of the frame ("Apples") will no longer match the current content of the frame ("Oranges").
To solve this problem, authors should always make the source ("src") of a frame an HTML file. Images may be inserted into the HTML file and their descriptions will evolve correctly.
Example.
<FRAME name="goodframe" src="apples.html" title="Apples"> <!-- In apples.html --> <HTML> ... <IMG src="apples.gif" alt="Apples"> ... </HTML>
Authors should not open windows or change active windows (e.g., by specifying a new window as the target of a frame with target="_blank") unless the user is aware that this is happening.
Authors should group form controls into semantic units with the FIELDSET element and label those units with the LEGEND element (both available in HTML 4.0):
Example.
<FORM action="http://somesite.com/adduser" method="post"> <FIELDSET> <LEGEND align="top">Personal information</LEGEND> <LABEL for="firstname">First name: </LABEL> <INPUT type="text" id="firstname" tabindex="1"> <LABEL for="lastname">Last name: </LABEL> <INPUT type="text" id="lastname" tabindex="2"> ...more personal information... </FIELDSET> <FIELDSET> <LEGEND align="top">Medical History</LEGEND> ...medical history information... </FIELDSET> </FORM>
Authors should use the LABEL element with the "for" attribute (available in HTML 4.0) to associate labels with their controls explicitly. For an example, see the previous section.
For long lists of selections (which are hard to remember), authors should group items into a hierarchy using the OPTGROUP element (available in HTML 4.0).
Example.
<FORM action="http://somesite.com/prog/someprog"
method="post">
<P>
<SELECT name="ComOS">
<OPTGROUP label="Comm Servers">
<OPTGROUP label="PortMaster 3">
<OPTION label="3.7.1" value="pm3_3.7.1">
PortMaster 3 with ComOS 3.7.1
<OPTION label="3.7" value="pm3_3.7">
PortMaster 3 with ComOS 3.7
<OPTION label="3.5" value="pm3_3.5">
PortMaster 3 with ComOS 3.5
</OPTGROUP>
<OPTGROUP label="PortMaster 2">
<OPTION label="3.7" value="pm2_3.7">
PortMaster 2 with ComOS 3.7
<OPTION label="3.5" value="pm2_3.5">
PortMaster 2 with ComOS 3.5
</OPTGROUP>
</OPTGROUP>
<OPTGROUP label="Routers">
<OPTGROUP label="IRX">
<OPTION label="3.7R" value="IRX_3.7R">
IRX with ComOS 3.7R
<OPTION label="3.5R" value="IRX_3.5R">
IRX with ComOS 3.5R
</OPTGROUP>
</OPTGROUP>
</SELECT>
</FORM>
Example.
<INPUT type="image" name="submit" src="button.gif" alt="Submit">
Authors must ensure that pages are accessible with scripts turned off or in browsers that don't support scripts.
Authors should provide alternative presentations of content for each script that conveys information. One way to accomplish this is with the NOSCRIPT element (available in HTML 4.0). The content of this element is rendered with scripts are not enabled.
Example.
<SCRIPT type="text/tcl">
...some Tcl script to show a billboard of sports scores...
</SCRIPT>
<NOSCRIPT>
<P>Results from yesterday's games:</P>
<DL>
<DT>Bulls 91, Sonics 80.
<DD><A href="bullsonic.html">Bulls vs. Sonics game highlights</A>
...more scores...
</DL>
</NOSCRIPT>
The original draft of this W3C working document is based on The Unified Web Site Accessibility Guidelines compiled by the Trace R & D Center, University of Wisconsin under funding from the National Institute on Disability and Rehabilitation Research (NIDRR), U.S. Dept. of Education.
For a full list of Contributors to the Unified Guidelines is available at http://trace.wisc.edu/docs/html_guidelines/version7.htm .
We would also like to thank the people
listed in the References section below whose
works were used in the compilation of the
unified guidelines on which this document is
based.
Under Construction
This index will list elements and attributes in alphabetical order and link each to pertinent techniques in this document as well as their definitions in the HTML 4.0 specification.