W3Ctechniques-19980908

Techniques for "WAI Guidelines: Page Authoring"

W3C Working Draft -8 September 1998

This version:
http://www.w3.org/WAI/GL/techniques-19980908
Latest version:
http://www.w3.org/WAI/GL/techniques
Editors:
Gregg Vanderheiden <po@trace.wisc.edu>
Wendy Chisholm <chisholm@trace.wisc.edu>
Ian Jacobs <ij@w3.org>

Copyright  ©  1998 W3C (MIT, INRIA, Keio ), All Rights Reserved.

Abstract

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.

While "WAI Guidelines: Page Authoring" strives to be a stable document (as a W3C Recommendation), the current document will undoubtedly evolve as technologies change and page authors discover more effective techniques for designing accessible pages.

This document is part of a series of accessibility documents published by the Web Accessibility Initiative.

Status of this document

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. The goal of the WAI-GL working group is discussed in our charter.

Comments

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.

Table of Contents

Rating and Classification
1 Accessibility Themes for HTML
2 HTML topics
Acknowledgments
References
Index of Elements and Attributes

Rating and Classification

Each technique in this document (introduced by the word "Technique") is rated according to the following system:

[Priority 1]
This technique must be implemented by an author, or one or more groups of users will find it impossible to access information in the document. Implementing this technique is a basic requirement for some groups to be able to use Web documents.
[Priority 2]
This technique should be implemented by an author, or one or more groups of users will find it difficult to access information in the document. Implementing this technique will significantly improve access to Web documents.
[Priority 3]
This technique may be implemented by an author to make it easier for one or more groups of users to access information in the document. Implementing this technique will improve access to Web documents.

Some techniques may have more than one rating. This occurs when the importance of the technique varies with the importance of the information being presented. For instance, if an author considers a vital chart or graph more important than a small graphic, it may be more important to implement a given technique for the former but not the latter.

The techniques in this document are numbered to match their numbering in "WAI Guidelines: Page Authoring".


1 Accessibility Themes for HTML

The following sections discuss some accessibility that authors should keep in mind as they design HTML documents.

1.1 Structure vs. Presentation

When designing a document or series of documents, page authors should strive to identify the desired structure for their documents without thinking about how the documents will be presented to the user. Distinguishing the structure of a document from how the content is presented offers a number of advantages, including improved accessibility, manageability, and scalability.

Identifying what is structure and what is presentation may be a challenging task at times that authors must develop a mindset for recognizing. For instance, many authors consider that a horizontal rule (the HR element) communicates a structural division. This may be true for sighted users, but to unsighted users or users without graphical browsers, a rule has next to no meaning (One might "guess" that an HR element implies a structural division, but without other information, there is no guarantee.) Authors should use the HTML 4.0 header elements (H1-H6) to identify new sections. These may be complemented by visual or other cues such as horizontal rules, but should not be replaced by them.

The inverse holds as well: authors should not use structural elements to achieve presentation effects. For instance, even though the BLOCKQUOTE element may cause indented text in some browsers, that is not its meaning, only a presentation side-effect. BLOCKQUOTE elements used for indentation confuse users and search robots alike, who expect the element to be used to mark up block quotations.

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 HTML presentation elements and attributes.

Elements and attributes that are deprecated in HTML 4.0 ([HTML40]) appear in red and followed by an asterisk (*) in this document. Most presentation elements have been deprecated in HTML 4.0.

Technique C.1.3 [Priority 2]: Authors should avoid deprecated elements whenever possible.

1.1.1 Structural elements and attributes

Document head and bodyHTML, HEAD, BODY
Data about the documentTITLE, META, ADDRESS
Attributesalt, title, longdesc
Chapters, sections, etc.H1-H6
Author-defined structuresDIV, SPAN
Attributesclass, id
Language, writing directionBDO
Attributeslang, hreflang, dir
Creating paragraphsEM, STRONG
Acronyms and abbreviationsACRONYM, ABBR
Subscripts and superscriptsSUB, SUP
Inserted and deleted textINS, DEL
Attributescite, datetime
QuotationsBLOCKQUOTE, Q
Attributescite
Identifying chunks of textDFN, CODE, SAMP, KBD, VAR, CITE
ListsUL, OL, LI, DL, DT, DD, DIR*,
Attributesstart*, value*
TablesTABLE, CAPTION, THEAD, TFOOT, TBODY, COLGROUP, COL, TR, TH, TD
Attributesabbr, axis, headers, scope, rowspan, span, summary
LinksLINK, IMG, OBJECT, PARAM, APPLET*, MAP, AREA
Attributesshape, ismap, coords
Forms and keyboard control FORM, INPUT, BUTTON, SELECT, OPTGROUP, OPTION, TEXTAREA, LABEL, FIELDSET, LEGEND, ISINDEX*
Attributestabindex, accesskey, label, for
ScriptsSCRIPT, NOSCRIPT

1.1.2 Presentation elements and attributes

Note 1. Not all attributes are listed in this section. Only those deemed pertinent to accessibility have been listed.

Note 2. While the STYLE element is presentational, it may be used to enhance the presentation of structural elements. The other presentation elements are often used instead of structural elements.

Style sheets PRE, CENTER*, BR , STYLE
Attributes align*, valign*, clear*, nowrap*, char, charoff , style
Spacing 
Attributes hspace*, vspace*, cellpadding, cellspacing, compact*, type*
Text style and fonts TT, I, B, BIG, SMALL, STRIKE*, S*, U*, FONT*, BASEFONT*
Attributes face*, size*
Colors 
Attributes background*, bgcolor*, color*, text*, link*, alink*, vlink*
Rules and bordersHR
Attributes border, noshade*, rules, size (deprecated according to element).
FramesFRAMESET, FRAME, IFRAME, NOFRAMES
Attributes target, marginheight, marginwidth, frame, frameborder, noresize, rows, cols, scrolling

1.2 Alternative text and descriptions

Text is considered accessible to almost all users since it may be handled by screen readers, non-visual browsers, braille readers, etc. It is good practice, as you design a document containing non-textual information (images, graphics, applets, etc.) to think about supplementing that information with textual equivalents wherever possible.

There are several types of textual supplements to consider:

Alternative text (Alt-text)
Alternative text represents the function of the content. Alternative text should not describe visual appearance or how something sounds. For example, if an image of a magnifying glass is used for a search button, the alt-text would be "Search" rather than "Magnifying glass".

Quicktest! A good test to determine if alternative text is useful is to imagine reading the document aloud over the telephone. What would you say upon encountering this image to make the page comprehensible to the listener?

Brief descriptions
Sometimes, a brief inline description of content (of a sound, an abbreviation, an image) may complement alt-text. In general, a brief description should describe visual appearance or how something sounds.
Long descriptions
In general, a long description should describe visual appearance or how something sounds. Long descriptions are generally stored in external documents (but may be inline if necessary).

HTML allows authors to specify these substitutes in several ways. Here is a summary of attributes used for alt-text and long descriptions and the elements they apply to (by version of HTML):

To implement alt-text, use the "alt" attribute.
In HTML 4.0, applies to: IMG, AREA, INPUT, APPLET. The attribute is mandatory for the IMG and AREA elements. For other elements, use the "title" attribute.
In HTML 3.2, applies to: IMG, AREA, APPLET.
In HTML 2.0, applies to: N/A.
To implement brief descriptions, use the "title" attribute
In HTML 4.0, applies to almost every element
In HTML 3.2, applies to: LINK, A
In HTML 2.0, applies to: N/A
To implement long descriptions, use the "longdesc" attribute
In HTML 4.0, applies to: FRAME, IFRAME, IMG
In HTML 3.2, applies to: N/A.
In HTML 2.0, applies to: N/A.

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:

Related techniques:

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.

1.3 Alternative pages

Although authors should avoid as much as possible document content for which there is no accessible alternative or supplement, it may happen that all or part of a page remains inaccessible. There are several techniques for creating accessible alternatives:

1.4 Keyboard access

Not every user has a graphic environment with a mouse or other pointing device. Some users rely on keyboard or voice input to navigate links, activate form controls, etc. Authors 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 two ways:

Keyboard shortcuts
Keyboard shortcuts allow users to combine keystrokes to navigate links or form controls on a page.
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).

Here is a summary of attributes used for keyboard access and tabbing order and the elements they apply to (by version of HTML):

To implement shortcuts, use the "accesskey" attribute.
In HTML, 4.0 applies to: A, AREA, BUTTON, INPUT, LABEL, LEGEND, TEXTAREA
In HTML, 3.2 applies to: N/A.
In HTML, 2.0 applies to: N/A.
To implement tabbing order, use the "tabindex" attribute
In HTML, 4.0 applies to: A, AREA, BUTTON, INPUT, OBJECT, SELECT, TEXTAREA
In HTML, 3.2 applies to: N/A
In HTML, 2.0 applies to: N/A

In the following example, if the accesskey "C" 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>

End example.

The next example assigns "U" as the access key. Typing "U" gives focus to the label, which in turn gives focus to the input control, so that the user can input text.

Example.

   <FORM action="submit" method="post">
         <LABEL for="user" accesskey="U">name</LABEL>
         <INPUT type="text" id="user">
   </FORM>

End example.

In the next example, we specify a tabbing order among elements (in order, "field2", "field1", "submit"):

Example.

   <INPUT tabindex="2" type="text" name="field1">
   <INPUT tabindex="1" type="text" name="field2">
   <INPUT tabindex="3" type="submit" name="submit">

End example.

Technique A.11.2 [Priority 2]: All elements that have their own interface should be keyboard operable. Some elements import objects whose interfaces cannot be controlled through HTML (applets, images, etc.) In such cases, users should ensure that the imported objects themselves provide accessible interfaces.

1.5 Graceful transformation

Authors should keep in mind, as they design pages, that certain users may not be equipped to perceive their intended presentation (due to physical limitation, an old browser, a browser a lacking specific feature, a browser not supporting an element, etc.). Pages should be designed to "transform gracefully" for such cases.

Technique A.9 [Priority 1]: Authors must ensure that pages using newer technology will transform gracefully if the technology is not supported or is turned off. To do so:

  1. Use alt-text, brief descriptions, and long descriptions.
  2. Test your pages on several browsers, old and new.
  3. Test your pages with a text-only browser such as Lynx or a Lynx emulator such as Lynx Viewer or Lynx-me.
  4. Test your pages without images.
  5. Test your pages without applets.
  6. Test your pages without scripts.
  7. Test your pages without style sheets.
  8. Test your pages without frames.

If, after completing these tests and adjusting your design accordingly, you find that your page is still not accessible, you must create an alternative page that is accessible.


2 HTML topics

The following sections list some techniques for using HTML and CSS to design accessible documents and some techniques for avoiding HTML accessibility traps. The sections are organized by topic (and mirror the organization of the HTML 4.0 specification, [HTML40]).

2.1 Document structure and metadata

As discussed above, authors should use structural markup wherever possible (and use it as intended by the authors of W3C specifications). Structural elements 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.

2.1.1 Metadata

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:

2.1.2 Section headers

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.

Technique A.6.1 [Priority 2]: Since some users skim through a document by navigating its headings, it is important to nest headings correctly, i.e., to follow an H1 with an H2, not and H3, and so on. 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.

2.2 Language information

Technique A.8.1 [Priority 2]: 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.

End example.

2.3 Text markup

As mentioned above, structural elements add information to a page that may be used by browsers, search engines, and other software. Authors are encouraged to use structural elements and attributes whenever possible. Below we discuss how to further improve accessibility by careful use of attributes with these elements.

2.3.1 Emphasis

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.)

2.3.2 Acronyms and abbreviations

Technique A.8.2 [Priority 2]: 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>!

End example.

2.3.3 Quotations

Technique A.6.3 [Priority 2]: 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. See the language example above for an illustration of the Q element.

Example.

   <BLOCKQUOTE cite="http://www.shakespeare.com/loveslabourlost">
     <P>Remuneration! O! that's the Latin word for three farthings.
        --- William Shakespeare (Love's Labor Lost).
     </P>
   </BLOCKQUOTE>

End example.

2.4 Lists

Technique A.6.2 [Priority 2]: Mark up and nest lists correctly. The HTML list elements DL, UL, and OL (available in HTML 3.2 and HTML 4.0) should only be used to create lists, not for formatting effects such as indentation.

Technique C.2.7 [Priority 3]: When possible, use ordered (numbered) lists to help navigation. Non-visual users often "get lost" in lists, especially those with several layers of embedding and those that do not indicate the specific level of indentation for each item. In addition, it is often difficult for non-visual users to know where the list itself begins and ends and where each list item starts. Finally, if a list entry wraps to the next line, it may appear to be two separate items in the list.

Example.

Instead of nesting bulleted lists like this:

which might be read by a screen reader (stripping bullets and indentation) as:
    writing tools
    pens
    highlighters
    red
    green
    blue
    ball-point
    green
    purple
    mauve
    pencils
    #2 lead
    soft lead
    erasers

Use ordered lists (or make sure to put distinguishing information at the beginning of each list item):

  1. writing tools
    1. pens
      1. highlighters
        1. red
        2. green
        3. blue
      2. ball-point
        1. green
        2. purple
        3. mauve
    1. pencils
      1. soft lead
      2. #2 lead
  2. erasers

End example.

2.4.1 Use style sheets to change list bullets

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>

End example.

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>
   <LI> 401(k)</LI>
</UL>

End example.

2.5 Tables

Page authors 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.

Example.
   <TABLE border="1" 
          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>

End example.

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="1" 
          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>

End example.

The following example shows how to create categories within a table using the "axis" attribute.

Example.

   <TABLE border="1">
     <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>

End example.

2.5.1 Wrapped text in tables

One source of problems for screen readers that do not interpret the source HTML is wrapped text in table cells. They read across the page, reading sentences on the same row from different columns as one sentence.

For example, if a table is rendered like this on the screen:

There is a 30% chance of               Classes at the University of Wisconsin 
rain showers this morning, but they    will resume on September 3rd. 
should stop before the weekend.

This might be read by a screen reader as:

There is a 30% chance of Classes at the University of Wisconsin
rain showers this morning, but they will resume on September 3rd. 
should stop before the weekend.

Screen readers that read the source HTML will recognize the structure of each cell, but for older screen readers, authors should minimize the risk of word wrapping by limiting the amount of text in each cell. Also, the longest chunks of text should all be in the last column (rightmost for left-to-right tables). This way, if they wrap, they will still be read coherently.

Authors should test tables for wrapping with a browser window dimension of "640x480".

Quicktest! To get a better understanding of how a screen reader would read a table, run a piece of paper down the page and read your table line by line.

2.6 Links

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 (the "link text") is read.

Technique B.4.2 [Priority 2]: 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.

Quicktest! To choose alt-text in this case, think of what you would say in words rather than an image in this context.

Example.

  <A href="routes.html">
     <IMG src="topo.html" 
          alt="Current routes at Boulders Climbing Gym">
  </A>

End example.

Technique B.4.1 [Priority 2]: If more than one link on a page shares the same link text, all those links should point to the same resource. Such consistency will help page design as well as accessibility.

Technique B.4.3 [Priority 2]: Link text should not be full sentences. Link text should be terse but complete.

2.7 Images and image maps

Images may be inserted by two elements in HTML:

IMG
Available in HTML 4.0, 3.2, 2.0
OBJECT
Available in HTML 4.0.

Images include those that carry out simple animations (e.g., a "gif" image).

2.7.1 Alternative text for images

Technique A.1.1 [Priority 1]: When using IMG, specify alt-text with the "alt" attribute.

Example.

   <IMG src="magnifyingglass.gif" alt="Search">     

End example.

Technique A.1.7 [Priority 1]: 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>

End example.

or in the body of the OBJECT element:

Example.

   <OBJECT data="magnifyingglass.gif" type="image/gif">
      Search 
   </OBJECT>

End example.

2.7.2 Brief descriptions for images

When using IMG, specify a brief description of the image with the "title" attribute:

Example.

   <IMG src="bell.gif" alt="Return to home page"
        title="Cow logo shaped like a bell">

End example.

2.7.3 Long descriptions for images

Technique A.2.1.1 [Priority 1]: When using IMG, specify a long description of the image with the "longdesc" attribute:

Example.

   <IMG src="97sales.gif" alt="Sales for 1997" 
        title="Sales pie chart"
        longdesc="sales97.html">

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.

Technique A.2.1.2 [Priority 1]: 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>

End example.

Technique A.2.2 [Priority 1]: 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 purchase ...
   </OBJECT>

End example.

Or, provide a link to a long description within the body of the element:

Example.

   <OBJECT data="97sales.gif" type="image/gif">
          Chart of our Sales in 1997.
          A <A href="desc.html">textual description</A> is available. 
  </OBJECT>

End example.

2.7.4 Ascii art

Replace ASCII art with an image and alt-text.

Technique A.1.6 [Priority 1 or 2]: Avoid ascii art (character illustrations) and use real images instead since it is easier to supply alt-text and long descriptions for images. The priority of this technique depends on the importance of the information (e.g., an important chart).

However, if ascii art must be used, mark it up as such:

Example.

<SPAN class="smile" title="smiley in ascii art">:-)</SPAN>

End example.

If the description of (important) ASCII art is long, provide a description in addition to alt-text.

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".

2.7.5 Client-side image maps

An image map is an image that has "active regions". When the user selects one of the regions, some action takes place -- a link may be followed, information sent to a server, etc. To make an image map accessible, authors must ensure that each action associated with a visual region may be activated without a pointing device. One way to achieve this is to provide a textual link for each active region. The alternative links should be navigable with the keyboard.

HTML allows two types of image maps: client-side (the user's browser processes a URI) 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).

Technique A.1.4 [Priority 1]: Don't use server-side image maps unless the same functionality or information is available in an alternative accessible format. If you must use a server-side image map, please consult the section on server-side image maps.

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:

AREA
Available in HTML 4.0, 3.2
A
Available in HTML 4.0.

For all image maps, authors should supply alt-text (described below), brief descriptions (see the section on brief descriptions for images), and long descriptions (see the section on long descriptions for images).

Technique A.11.1 [Priority 1]: Provide alternative text for image maps since they convey visual information.

Technique A.1.3.1 [Priority 1]: 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>

End example.

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>

End example.

Technique A.1.3.2 [Priority 1]: In addition to providing alt-text, provide redundant textual links. If the A element is used instead of AREA, the author may describe the active regions and provide redundant links at the same time:

Example.

   <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>

End example.

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.

Technique A.12.2 [Priority 3]: Authors should make sure they include printable characters (such as brackets or a vertical bar (|)) surrounded by spaces between adjacent links.

2.7.6 Server-side image maps

When a server-side image map must be used, authors should provide an alternative list of image map choices. There are three techniques:

Technique A.1.5.2 [Priority 2]: Authors should avoid using a button with an image on it as a server side image map. Use separate buttons or images instead (with alt-text).

2.8 Applets and other objects

Applets may be inserted by two elements in HTML:

APPLET
Available in HTML 4.0 (deprecated), 3.2.
OBJECT
Available in HTML 4.0.

There are several techniques that authors should use to ensure that audio or visual information presented by an applet is accessible:

  1. Technique [Priority 1]: Provide alt-text" and, where needed, a long description (described below).
  2. Technique A.10.1 [Priority 1 or 2]: 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 (see the section on accessible applets).
  3. Technique A.9.4.2 [Priority 2]: If possible, provide the same information in a format other than an applet (e.g., a video, an image, etc.).

2.8.1 Alternative text for applets

Technique A.9.4.1.1 [Priority 1]: 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>

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.

  <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>

End example.

Technique A.1.2 [Priority 1]: If APPLET is used, provide alt-text with the "alt" attribute and content in the APPLET element. This enables them to transform 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>

2.8.2 Long descriptions for applets

See the section on long descriptions for images. See discussion of applet long descriptions in the guidelines.

2.8.3 Accessible applets

For more information about accessible applets, please see:

2.0 Audio and video

Audio and video should be accompanied by text transcripts, text descriptions of audio or visual 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. Full audio transcripts include spoken dialogue as well as any other significant sounds including on-screen and off-screen sounds, music, laughter, applause, etc.

Example.

Here's an example of a transcript of a clip from "The Lion King" (available at the WGBH/NCAM Descriptive Video Service site).

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.

2.9.1 Audio information

Technique A.3.1 [Priority 1]: For stand-alone audio files, provide a textual transcript of all words spoken or sung as well as significant sounds.

Technique A.3.2 [Priority 1]: For audio associated with video, synchronize a textual transcript (of dialog and sounds) with the video (e.g., captions).

Some media formats, such as QuickTime 3.0, allow captions and video descriptions to be added to the multimedia clip.

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. Future technologies, on the other hand, will allow separate audio/visual files to be combined with text files via a synchronization file to create captioned audio and movies. It will 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.

Technique A.3.3 [Priority 1 or 2]: Where sounds are played automatically, provide visual notification and transcripts.

This 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 consult NCAM's discussions of captioning and audio description on the Web

2.9.2 Visual information and motion

Video descriptions are used primarily by people who are blind to follow the action and other non-auditory information in video material. The description provides 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.

Technique A.4.2 [Priority 1]: For movies, provide auditory descriptions that are synchronized with the original audio. See the section on audio information for more information about multimedia formats.

Technique A.4.3 [Priority 2]: Provide a text version of the auditory description that is collated with the text transcript (captions) of the primary audio track. This text transcript, in conjunction with the full audio transcript described above, allows access by people with both visual and hearing disabilities. This also provides everyone with the ability to index and search for information contained in audio/visual materials.

Technique A.7.1 [Priority 3]: Authors should avoid creating motion in pages.

Technique A.7.2 [Priority 2]: However, if necessary to include an applets that involves motion or updates, authors should provide a mechanism for freezing this motion. In an example of motion 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 motion that may be suspended by the browser for people that have trouble with it.

Technique A.4.1 [Priority 1]: For animated images, provide both alt-text and a brief descriptions.

See also the section on text style for controlling blinking.

2.10 Style and style sheets

Technique A.6.4 [Priority 2]: Style sheets should be used to control layout and presentation wherever possible in a document. CSS1 ([[CSS1]) and CSS2 ([[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. In the following sections, we show how style sheets may be used to create accessible pages. We also provide examples of how to use HTML 4.0 features (e.g., tables, bitmap text) more accessibly when they must be used.

2.10.1 General style sheet techniques

2.10.2 Text formatting

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.

However, if you must use a bitmap to create a text effect (special font, transformation, shadows, etc.) it must be accessible.

Technique A.6.4 [Priority 1]: When bitmapped text is used in a way that makes a page inaccessible, authors must supply alternative pages.

To make a bitmap representing text accessible, it must have alt-text that is the same text represented by the image.

Example.

In this example, the inserted image shows the large red characters "Example", reflected by the alt-text.

<P>This is an 
   <IMG src="BigRedExample.gif" alt="Example"> of what we mean.
</P>

End example.

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.

Example.

<STYLE ...>
      .dropcap { font-size : 120%; font-family : Helvetica } 
</STYLE>
...
<P><SPAN class="dropcap">O</SPAN>nce upon a time...

Note. As of the writing of this document, the CSS pseudo-element ':first-letter', which allows authors to refer to the first letter of a chunk of text, is not widely supported.

2.10.3 Text style

Authors should use style sheets instead of deprecated presentation elements and attributes that control visual presentation.

2.10.4 Fonts

Instead of using deprecated presentation elements and attributes, 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'.

2.10.5 Colors

Use these CSS properties to specify colors:

Technique A.5.1 [Priority 1]: 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."

Quicktest! To text whether your page passes the text, examine it with a monochrome monitor or colors turned off.

Technique A.5.2 [Priority 1]: 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).

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).

For more information about colors and contrasts, please consult The Lighthouse.

2.10.6 Layout, positioning, and alignment

Layout, positioning, and alignment should be done through style sheets (notably by using CSS floats and absolute positioning).

When laying out tabular information, authors should use tables that are designed for accessibility (see the section on tables. Do not use PRE to create a tabular layout of text. Technique A.12.5 [Priority 2]: However, until user agents and screen readers are able to handle text presented side-by-side, all tables that lay out text in parallel, word-wrapped columns require a linear text alternative (on the current page or some other). See also the section on tables for additional information on table accessibility.

Technique A.1.1 [Priority 1]: Provide alternative text for all images, including invisible or transparent images.

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&nbsp;" 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="&nbsp;&nbsp;&nbsp;">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">

2.10.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.

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>

End example.

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>
   <HR class="redline" title="End of Chapter 7 - Visual Displays">
   <H1>Chapter 8 - Auditory and Tactile Displays</H1>

End example.

2.11 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.

2.11.1 Name frames for easy orientation

Technique B.1.1 [Priority 1]: For reasons of orientation, all frames should all be identified with the "title" attribute.

Example.

<FRAMESET cols="10%,90%"
          title="Our library of electronic documents">  
    <FRAME src="nav.html" title="Navigation bar">  
    <FRAME src="doc.html" title="Documents">
    <NOFRAMES>
       <A href="lib.html" title="Library link">   
             Select to go to the electronic library</A>  
    </NOFRAMES>
</FRAMESET>

End example.

2.11.2 Brief descriptions of frames

Technique B.1.1 [Priority 2]: Authors should provide a brief description of each frame with the "title" attribute.

2.11.3 Long descriptions of frames

Technique B.1.2 [Priority 2]: Authors should provide a long description of a frame (where needed) by using either "longdesc" or "d-links" in a NOFRAMES element.

Example.

In this example, the file "chart.html" inserts a complex chart. The "longdesc" attribute designates the file "chart-desc.html", which contains a long description of the chart.

<FRAMESET cols="20%, 80%">
     <FRAME src="table_of_contents.html">
     <FRAME src="chart.html" longdesc="chart-desc.html">
</FRAMESET>

Note that if the second frame's contents change (from "chart.html"), the long description will no longer apply. Long descriptions of frames should only be used for frames with static contents.

End example.

2.11.4 Ensure documents are readable without frames

Technique A.9.1.1 [Priority 1]: 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 the content is displayed">
       <FRAME src="table_of_contents.html" title="Table of Contents">
       <NOFRAMES>
           <A href="table_of_contents.html">Table of Contents.</A>
	    <!-- other navigational links that are available in main.html
	         are available here also. -->
       </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.

End example.

2.11.5 Always make the source of a frame an HTML document

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").

Technique A.9.1.2 [Priority 1]: 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>

End example.

2.11.6 Avoid opening a new window as the target of a frame

Technique A.12.3 [Priority 2]: 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.

2.12 Forms

2.12.1 Make controls keyboard accessible

Technique A.11.3 [Priority 3]: Authors should define a tabbing order through form controls.

Technique A.11.4 [Priority 3]: They should also provide keyboard shortcuts. See the section on keyboard access for more information.

2.12.2 Group form controls

Technique B.2.1 [Priority 2 for radio buttons and check boxes, Priority 3 otherwise]: 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>

End example.

2.12.3 Label form controls explicitly

Technique B.2.2 [Priority 2]: Authors should use the LABEL element with the "for" attribute (available in HTML 4.0) to associate labels with their controls explicitly. An example is given in the previous section.

However, for labels not associated with a control through "for", authors should ensure one of the following:

2.12.4 Group menu options

Technique B.2.3 [Priority 2]: 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>

End example.

2.12.5 Techniques for specific controls

Technique A.12.1 [Priority 3]: Include default, place-holding characters in edit boxes and text areas (TEXTAREA, INPUT).

Example.

<FORM action="http://somesite.com/prog/text-read" method="post">
     <P>
     <TEXTAREA name="yourname" rows="20" cols="80">
     Please enter your name here.
     </TEXTAREA>
     <INPUT type="submit" value="Send"><INPUT type="reset">
     </P>
</FORM>

End example.

Technique A.1.5.1 [Priority 1]: Provide alt-text for images used as "submit" buttons:

Example.

<INPUT type="image" name="submit" src="button.gif" alt="Submit">

End example.

Technique A.1.5.2 [Priority 2]: Authors should avoid using a button with an image on it as a server side image map. Use separate buttons or images instead (with alt-text).

Also see the section on keyboard access since this applies to form controls.

2.13 Scripts

Authors must ensure that pages are accessible with scripts turned off or in browsers that don't support scripts.

2.13.1 Alternative presentation of scripts

Technique A.9.2 [Priority 1]: Authors should provide alternative presentations of content for each script that conveys important 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>

End example.


Acknowledgments

WAI Markup Guidelines Working Group Co-Chairs:
Chuck Letourneau, Starling Access Services
Gregg Vanderheiden, Trace Research and Development
Staff contacts:
Judy Brewer and Daniel Dardailler
 
Special thanks to the following people who have made major contributions to shaping the content of this Working Draft:
Harvey Bingham, Daniel Dardailler, Al Gilman, Jason White
 
In addition we would like to thank the following people who have contributed through review and comment:
Judy Brewer, Kevin Carey, Chetz Colwell, Neal Ewers, Geoff Freed, Larry Goldberg, Jon Gunderson, Phill Jenkins, Leonard Kasday, George Kerscher, Josh Krieger, Scott Luebking, William Loughborough, Murray Maloney, Charles McCathieNevile, MegaZone (Livingston Enterprises), Masafumi Nakane, 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

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.


References

Normative References

[CSS1]
"CSS, level 1 Recommendation", B. Bos, H. Wium Lie, eds. The CSS1 Recommendation 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. The CSS2 Recommendation is available at:
http://www.w3.org/TR/REC-CSS2/.
[HTML40]
"HTML 4.0 Recommendation", D. Raggett, A. Le Hors, and I. Jacobs, eds. The HTML 4.0 Recommendation is available at:
http://www.w3.org/TR/REC-html40/.
[HTML32]
"HTML 3.2 Recommendation", D. Raggett, ed. The HTML 3.2 Recommendation is available at:
http://www.w3.org/TR/REC-html32.
[SMIL]
"Synchronized Multimedia Integration Language (SMIL) 1.0 Specification", P. Hoschka, editor. The SMIL 1.0 Recommendation is available at:
http://www.w3.org/TR/REC-smil/

Index of elements and attributes

Elements

This index lists all elements in HTML 4.0 and whether they are defined in earlier versions of HTML. Elements and attributes that are deprecated in HTML 4.0 ([HTML40]) are followed by an asterisk (*). Elements that are obsolete in HTML 4.0 or don't exist in any version of HTML (2.0, 3.2, 4.0) do not appear in this table. An entry of "N/A" means that an element is not discussed in this document.

NameAlso defined inRelated HTML topics
A2.0, 3.2 Keyboard access, Links
ABBR  Acronyms and abbreviations
ACRONYM  Acronyms and abbreviations
ADDRESS2.0, 3.2 Metadata
APPLET*3.2 Applets and other objects
AREA3.2 Keyboard access, Images and image maps,
B2.0, 3.2 Text style, Emphasis
BASE2.0, 3.2 Links
BASEFONT*3.2 Fonts
BDO N/A
BIG3.2 Text style
BLOCKQUOTE2.0, 3.2 Quotations, Text style
BODY2.0, 3.2N/A
BR2.0, 3.2 Layout, positioning, and alignment
BUTTON  Keyboard access, Server-side image maps, Forms
CAPTION  Tables
CENTER*3.2 Layout, positioning, and alignment
CITE2.0, 3.2N/A
CODE2.0, 3.2N/A
COL  Tables
COLGROUP  Tables
DD2.0, 3.2 Lists
DEL N/A
DFN3.2N/A
DIR*2.0, 3.2N/A
DIV3.2N/A
DL2.0, 3.2 Lists
DT2.0, 3.2 Lists
EM2.0, 3.2 Emphasis, Text style
FIELDSET  Grouping form controls
FONT*3.2 Fonts
FORM2.0, 3.2 Forms
FRAME  Frames
FRAMESET  Frames
H1-H62.0, 3.2 Section headers
HEAD2.0, 3.2N/A
HR2.0, 3.2 Rules and border, Section headers
HTML2.0, 3.2N/A
I2.0, 3.2 Text style, Emphasis
IFRAME  Frames
IMG2.0, 3.2 List bullets,
INPUT2.0, 3.2 Images and image maps, Keyboard access, Layout, positioning, and alignment, Rules and borders
INS N/A
ISINDEX*2.0, 3.2N/A
KBD2.0, 3.2N/A
LABEL  Keyboard access, Form labels
LEGEND  Keyboard access,
LI2.0, 3.2 Lists
LINK2.0, 3.2 Links, Metadata
MAP3.2 Images and image maps
MENU*2.0, 3.2N/A
META2.0, 3.2 Metadata
NOFRAMES  Frames
NOSCRIPT  Scripts
OBJECT  Keyboard access, Images and image maps, Applets and other objects
OL2.0, 3.2 Lists
OPTGROUP2.0, 3.2 Forms
OPTION2.0, 3.2 Forms
P2.0, 3.2N/A
PARAM  Forms
PRE2.0, 3.2 Layout, positioning, and alignment, Text style
Q  Quotations
S  Text style
SAMP2.0, 3.2N/A
SCRIPT  Scripts
SELECT2.0, 3.2 Keyboard access, Forms
SMALL3.2 Text style
SPAN N/A
STRIKE*3.2 Text style
STRONG2.0, 3.2 Emphasis, Text style
STYLE  Keyboard access,
SUB3.2N/A
SUP3.2N/A
TABLE3.2 Tables
TBODY  Tables
TD3.2 Tables
TEXTAREA2.0, 3.2 Keyboard access, Forms
TFOOT  Tables
TD3.2 Tables
THEAD  Tables
TITLE2.0, 3.2 Metadata
TR3.2 Tables
TT2.0, 3.2 Text style
U3.2 Text style
UL2.0, 3.2 Lists
VAR2.0, 3.2N/A

Attributes

Attributes that are deprecated in HTML 4.0 ([HTML40]) are marked up in this document and followed by an asterisk (*). Attributes that are obsolete in HTML 4.0 or don't exist in any version of HTML (2.0, 3.2) do not appear in this table. An entry of "N/A" means this attribute is not discussed in this document.

Under construction