W3C   WD-WAI-PAGEAUTH-0410

WAI Accessibility Guidelines:
Page Authoring

W3C Working Draft     10-Apr-1998

This version:
http://www.w3.org/TR/1998/WD-WAI-PAGEAUTH-0410
Latest version:
http://www.w3.org/TR/WD-WAI-PAGEAUTH
Previous versions:
http://www.w3.org/WAI/GL/WD-WAI-PAGEAUTH-0203
Editors:
Gregg Vanderheiden, Trace Research and Development
Wendy Chisholm, Trace Research and Development
Ian Jacobs, W3C
 
Please see the Acknowledgements section of the Appendix for a full listing of contributors.

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, and is intended as a draft of a proposed recommendation for how to make Web pages accessible. The goal of the WAI-GL working group is discussed in our charter.

Abstract

This document is a list of markup guidelines that HTML authors should follow in order to make their pages more accessible for people with disabilities as well as usable by indexing robots. Following the list of guidelines is a checklist that authors and Web masters should use to verify page accessibility. Tools that generate documents in HTML (authoring tools, file conversion packages or other products) should produce documents that follow these guidelines.  This document is part of a series of accessibility documents published by the Web Accessibility Initiative.

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.

Note: some people have encountered problems printing this page due to the use of style sheets.  We have tried to correct the problem but ask that people help us explore solutions.


Table of Contents

Introduction
Rating and Classification
1. Style and Structure
2. Images and Image Maps
3. Applets and Scripts
4. Audio and Video
5. Tables
6. Links
7. Frames
8. User-Input Forms
9. If All Else Fails...
10. Good Web Site Design Practices
Appendix A - Table examples
Appendix B - Alt-text authoring guidelines
Checklist
Acknowledgements
References

Introduction

This document recommends guidelines that HTML authors should follow in order to improve the accessibility of their pages. Some of the guidelines take advantage of the features of HTML 4.0, but many of them apply to earlier versions of HTML as well.

Measures to improve accessibility fall roughly into the following categories:

Structure
HTML documents that contain a lot of markup used for presentation and not enough markup to convey structure pose accessibility problems for non-visual users. Authors should use HTML structural markup to convey meaning and style sheets to format and layout pages.
Navigation
Authors should enable keyboard-only navigation  (access to hyperlinks, navigation among links, navigation among form fields, navigation within and between pages) and design pages that promote easy orientation (numbered lists, titles, etc.).
Alternative format
Authors should always provide alternative ways to access information presented via images, sounds, applets, and scripts. For example, captions and transcripts provide auditory information in a form accessible to people unable to hear it.  A textual replacement of a graphic, either a description of its content or function, provides information in a form accessible to people unable to see it.

The following sections offer specific guidelines that HTML authors should use to improve the accessibility of their pages.


Rating and Classification

Each guideline is accompanied by a rating that describes its importance:

[Required]
Required, otherwise it will be impossible for one or more groups of users to understand the page.
[Recommended]
Makes page easier to understand and use.

Each guideline may be implemented by one or more "strategies" in HTML (and possibly a style sheet language). Each strategy may be classified according to the immediacy of its application:

[Interim]
This strategy is necessary to make pages accessible for today's browsers and assistive technologies
[New]
This strategy takes advantage of features being incorporated into tomorrow's browsers and assistive technologies (that incorporate Web Access Initiative recommendations).

Strategies with no classification work for versions of HTML prior to HTML 4.0, and old or new browsers.


1. Style and Structure

  1. [Required]
      Use elements that comply with the strict HTML 4.0 Definition and the current style sheet specification.
    The W3C offers an HTML validation service at  http://validator.w3.org/ that can be used to determine if a site complies with the HTMl 4.0 Definition.
  2. [Required]
      Ensure that pages are readable and usable without style sheets
    for browsers that do not support them or users who deactivate them. Since style sheets are a new phenomenon, older browsers will not support them and it will take a while for new browsers to support them in a standard way.

  3. [Required]
      Nest headings properly.
    Proper nesting of heading is important for document navigation. Headings used for other purposes (e.g., for formatting text in a larger font size) may disorient users; use style sheets for formatting.

  4. [Required]
      Encode list structure and list items properly.
    The HTML list elements (DL, UL, OL, LI) should only be used to create lists.   Avoid using list elements for presentation effects such as  indentation.

    [New] Use style sheets rather than HTML attributes to control item spacing. Note:  item 7.

  5. [Required]
      Avoid blinking or scrolling text.
    [Interim] Authors should avoid the BLINK and MARQUEE elements. First of all, these elements are not part of HTML 4.0 (they are proprietary extensions and should be avoided). Second, blinking and moving text  is either read incorrectly or not at all by screen readers, can adversely affect people with cognitive disabilities, and is often annoying to people in general (see Jared Spool's book, "Web Site Usability"). Authors should use style sheets to draw attention to text in other ways, such different fonts, sizes, or colors.

  6. [Recommended]
      Use style sheets 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, a particular color combination such as white on black, or in a particular font.

  7. [Recommended]
      Use style sheets rather than invisible or transparent images to force layout.
    [Note:  Current (April 1998) browsers do not yet support use of style sheets for some types of positioning, such as absolute.]

  8. [Recommended]
      Avoid the use of deprecated presentation elements (TT, ALIGN, BORDER, FONT, and BACKGROUND) as well as (B and I).
    Authors should use style sheets instead of presentation elements and attributes (such as "align") that control visual presentation. Authors are encouraged to use elements (such as STRONG, EM, H1, H2, ABBR, etc.) that add structure to documents.   Documents that use style sheets for presentation allow users to adjust the look of the document (e.g., larger print, color contrast, etc.) through personal style sheets or browser settings.

  9. [Recommended]
      Use elements and attributes that appropriately convey structure.
    Phrase elements include: EM, STRONG, DFN, CODE, SAMP, KBD, VAR, CITE, ABBR, and ACRONYM
    Structural elements:  H1, H2,
    Structural elements enforce consistency in documents and supply information to other tools (e.g., indexing tools, search engines, programs that extract tables to databases, browsers that use header elements ( H1, H2, etc.) to generate navigation tools, etc.).

  10. [Recommended]
      Do not misuse structural elements and attributes for purposes of layout.
    For example, do not use the BLOCKQUOTE element or the "cite" attribute to indent a paragraph (use style sheets). Do not use PRE to create a tabular layout of text (use tables).

  11. [Recommended]
      Do not misuse presentation elements for purposes of structure.
    For example, while a horizontal rule (HR) might convey a structural change to some users, it may not to all users. Instead, specify structure with DIV and SPAN. For example:
    <DIV class="navigation-bar">
    <HR title="Navigation bar">
    [ <A rel="Next" href="next.html">Next page</A> |
      <A rel="Previous" href="previous.html">Previous page</A> |
      <A rel="First" href="first.html">First page</A> ]
    </DIV>
    
  12. [Recommended]
      Provide titles for horizontal rules, acronyms, and abbreviations. 
    For example:
    <HR title="new section">
    <ABBR title="Idaho">Id.</ABBR>
    <ACRONYM title="World Wide Web">WWW</ACRONYM>

Tips and Tricks

For more information:

  1. Style Sheets - Chapter 14 in the Central Reference Document
  2. Style Sheets - the HTML 4.0 specification
  3. Cascading Style Sheets, level 2 -- Working Draft from the World Wide Web Consortium
  4. Text - Chapter 9 in the Central Reference Document
  5. Text - the HTML 4.0 specification
  6. Lists and Outlining - Chapter 10 in the Central Reference Document
  7. Lists - the HTML 4.0 specification

2. Images and Image maps

Please also consult the section on links.

  1. [Required]
    Provide alternative text for all images and image maps.

    Each image should have alternative text that represents the function of the graphic. Aim for a functional label based on the context in which it is used rather than a visual description.  A good test to determine if alt-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?  Possible strategies for providing alternative text include:
    1. The "alt" attribute is mandatory for the AREA and IMG elements. It should also be used for buttons used as submit buttons on forms (INPUT type = image). For example: <IMG src="magnifyingglass.gif" alt="Search">. However, the recommendations for alt-text vary depending on how the graphic is used (decoration, button, bullet, illustration, etc.).  Please see Appendix B - Alt-text authoring guidelines for more information.
    2. [New] If OBJECT is used, text can be provided in the body of the OBJECT element.  For example:
      <OBJECT data="logo.gif">XYZ Logo</OBJECT>

    Note: Longer descriptions of the appearance of an image may be provided.  See the next recommendation for solution strategies.

  2. [Required]
    Provide a longer description for graphics that present important information (especially charts, tables, and diagrams).

    Alternative text (see strategy 2.1 above) are usually short and define the basic purpose of graphic elements. To describe the graphic itself in more detail, supply a longer description with one of the following mechanisms (most of these are methods to link to additional information):
    1. [Interim] Provide a description-link (D-link) next to the graphic that links to a page or a phrase at the bottom of the page with a longer description of the graphic. For example:
      <IMG src="97sales.gif" alt="Sales for 1997">
      <A href="sales.html">D</A>
    2. [New] Use the "longdesc" attribute of the IMG element. For example:
      <IMG src="97sales.gif" alt="Sales for 1997" longdesc="sales.html">
    3. [New] Provide text within the body of the OBJECT element:
      <OBJECT data="sales.gif">
      Sales in 1997 were down subsequent to ...
      </OBJECT>
    4. Include internal text in image data file when the image data file format supports it, e.g. PNG.

  3. [Required]
    Use client-side (instead of server-side) image maps.

    Client-side image maps allow browsers that are not displaying graphics to use "alt" or "title" attribute values  to construct a list of links in place of the image map graphic.

    When a server-side image map must be used, authors should provide an alternate list of image map choices. For example, authors may put the alternate links on the same page in the body of an OBJECT element (similar to strategy 2.4.2), or create an alternative page that is accessible. To avoid confusion, if an alternative list of links follows the image map, authors should indicate with the "alt" attribute of the MAP element that there is an alternate list and its location.

  4. [Required]
    Provide a description for each link in an image map.

    Depending on the image map, there are several possibilities:
    1. If the MAP element has been used with AREA, set the "alt" attribute of the AREA element. For example, with the IMG element:
      <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>
      

      [New] The same idea, this time using the OBJECT element with flexibility to include more information:

      <OBJECT data="welcome.gif" usemap="#map1">
       There are several areas in the library  including 
       <A href="reference.html">Reference</A>
       and <A href="media.html"> the Audio VisualLab</A>.  
       More text can follow or precede.
      <MAP name="map1">
         <AREA shape="rect" coords="0,0,30,30" 
               href="ref.html" alt="Reference">
         <AREA shape="rect" coords="34,34,100,100" 
               href="media.html" alt="Audio Visual Lab">
      </MAP></OBJECT>
      
    2. [New] The MAP element can be used with A elements to specify active region geometries and provide contextual information.
      <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="circle" coords="184,200,60">Search</A> |
       <A href="top10.html" 
          shape="poly" coords="276,0,373,28,50,50,276,0">Top Ten</A>
      </MAP>
      </OBJECT>
      

      Note in this example that the MAP element is the content of the OBJECT element so that the alternate links will only be displayed if the image map (navbar1.gif) is not.

  5. [Recommended]
    Provide descriptive titles for all images used as links.

    Use the "title" attribute of the A element to provide more information about images used as links. For example:
    <A href="home.html" title="Search the whole XYZ company site">
       <IMG src="magnifyingglass.gif" alt="Search">
    </A>
    
  6. [Recommended]
    Avoid ASCII art. Replace it with an image and alternative text.

    Common typographic characters or constructions to be avoided are emoticons and arrows consisting of dashes and greater than signs (e.g., -->), etc.

For more information:

  1. From the Central Reference Document
    1. 13.1 Introduction to the issues
    2. 13.2 General recommendations
    3. 13.3 Viewing and interacting with static images and image maps
  2. Objects, Images and Applets - the HTML 4.0 specification

3. Applets and Scripts

  1. [Required]
     Provide alternative text for each script.

    [New] The NOSCRIPT element allows authors to supply alternative content for scripts. For example:
    
    <SCRIPT type="text/tcl">
    ...some Tcl script to show a billboard of sports scores...
    </SCRIPT>
    <NOSCRIPT>
    <P>To access today's scores, 
    <A href="scores.html">visit our text-only version.</A>
    </NOSCRIPT>
    
    
  2. [Required]
      Provide alternative text for each applet.
    1. [Interim] Use the "alt" attribute of the APPLET element, as in:
      
      <APPLET code="Press.class" width="500" height="500" 
              alt="Java applet: how temperature affects pressure.">
      As temperature increases the molecules in the balloon...
      </APPLET>
      

      Note. The APPLET element is deprecated in HTML 4.0.

    2. [New] When using the OBJECT element, specify alternative content:
      
      <OBJECT classid="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 version takes advantage of the fact the OBJECT elements may be embedded to provide for alternative representations of information:

      
      <!-- First, try the pressure applet -->
      <OBJECT title="How temperature affects pressure"
              classid="Press.class" width="500" height="500">
         <!-- Else, try the MPEG video -->
         <OBJECT data="pressure.mpeg" type="application/mpeg">
            <!-- Else, try the GIF image -->
            <OBJECT data="Pressure.gif">
               <!-- Else render the description and an alternative -->
               As temperature increases the molecules in the balloon...
      </OBJECT></OBJECT></OBJECT>
      
      
  3. [Required]
      Provide descriptions of applets that present important information.
    1. [Interim] Supply a description as content of the APPLET element (see the example in 3.2.1).
    2. [New] Supply a description as content of the OBJECT element (see the example in 3.2.2).

  4. [Required]
    If an applet gathers information, provide an alternative mechanism for gathering the information.

    Alternative information gathering mechanisms such as a user-input form, e-mail address, phone or fax number should be provided within the alternative text of either the APPLET or OBJECT elements.

  5. [Required]
    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.

    More information is available through  the Java Accessibility page at the Trace Center.

  6. [Required]
      Provide a mechanism for the user to freeze any moving or blinking objects, particularly those that contain text.
    In the following example created by Mark Novak, if the user presses the escape key while the Java marquee has focus, the text will be displayed statically.

  7. [Recommended]
      Make scripts and applets keyboard-operable (using standard conventions).

Note. More exploration is needed in this area. Please stay tuned.

For more information:

  1. From the Central Reference Document
    1. 13.1 Introduction to the issues
    2. 13.2 General recommendations
    3. 13.4 Applets
    4. 18 Scripts
  2. Objects, Images and Applets - the HTML 4.0 specification
  3. Scripts - the HTML 4.0 specification
  4. IBM Guidelines for Writing Accessible Applications Using 100% Pure Java -- IBM Special Needs Systems

4. Audio and Video

  1. [Required]
      Provide a text transcript of all audio information.
    Full audio transcripts include spoken dialogue as well as any other significant sounds including on-screen and off-screen sounds, music, laughter, applause etc. 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. 

  2. [Required]
      Provide descriptions of all video information in an auditory form, synchronized with the audio track.
    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. 

  3. [Required]
      Provide descriptions of all video information in a text format.
    A text transcript of the video descriptions provides the same information as in recommendation 4.2, but in a text format. 
    This text transcript, in conjunction with the full audio transcript (4.1), 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.

  4. [Required]
      Synchronize text and video description information with audio/video information, either directly or via a synchronization file.
    Some media formats such as QuickTime (for Macintosh) movies provide alternative tracks that can be used to add captioning and video descriptions.
    1. [Interim] Until the format in question supports alternative tracks, two versions of the movie could be made available, one with captions and descriptive video, and one without.
    2. [New] Future technologies 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 specification.
  5. [Recommended]
      Provide visual notification of sounds that are played automatically.
    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. The controversy surrounding this recommendation is that 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.

  6. [Recommended]
    Use the "title" attribute to provide a brief description of a very short sound.
    For example: <A href="mittens.wav" title="meow">Calico says "hello"</A>

For more information:

  1. From the Central Reference Document
    1. 13.1 Introduction to the issues
    2. 13.2 General recommendations
    3. 13.5 Audio and video
  2. Objects, Images and Applets - the HTML 4.0 specification
  3. Examples from NCAM

5. Tables

  1. [Required]
      Associate table cells with row and column labels explicitly.
    Future browsers and assistive technologies will be able to automatically translate tables into linear sequences if tables are labeled appropriately. [New] One way of labeling cells is with the "headers" and "scope" attributes. Please refer to the first two tables examples in the appendix.

  2. [Required]
      Avoid using tables to arrange text documents in columns.

  3. [Recommended]
      For tables of text and numbers, provide an alternative page that presents the table information in a linear fashion.

  4. [Recommended]
      Avoid using tables to layout a page.
    [New] Authors should use style sheets to position graphics and text.

  5. [Recommended]
      Provide abbreviations for lengthy row or column labels.
    [New] Row and column header abbreviations (the "abbr" attribute) should be short but meaningful.  This will be particularly useful for future speaking technologies that will read row and column labels for each cell.   Abbreviations cut down on repetition and reading time.  Please refer to the examples in the appendix.

  6. [Recommended]
      Provide summaries of tables.
    [New] Summaries of table structure and purpose (the "summary" attribute of the TABLE element) are especially useful for non-visual users.  Please refer to the examples in the appendix.

  7. [Recommended]
      For more complex tables, group information into categories.
    [New] Future browsers will allow users to select data from a table by filtering on categories.  Please refer to the third example (the "axis" attribute) in the appendix.

  8. [Recommended]
      Ensure that alternative text does not wrap within tables used to position graphics.
    [Interim] Test for wrapping using the equivalent window size as that which can maximally fit on a 15-inch monitor using a common resolution such as 800x600 pixels.

  9. [Recommended]
      Provide a phone number, fax number or e-mail address if tables cannot be made accessible.

Tips and Tricks

For more information:

  1. Tables - Chapter 11 in the Central Reference Document
  2. Tables - the HTML 4.0 specification

6. Links

Please also consult the section on image maps.

  1. [Recommended]
      Create link phrases that make sense when read out of context, but that are not too verbose.
    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 click here."

  2. [Recommended]
      Place non-link,  printable characters (surrounded by spaces)  between links that occur consecutively to keep separate links from being read as one by screen readers (e.g., " | ").
    [Interim] Please consult the example provided in guideline 5.3.

  3. [Recommended]
    Provide keyboard shortcuts for links.
    The "accesskey" attribute of the LABEL, A, CAPTION and LEGEND elements allows an author to associate a keyboard shortcut with the phrase. For example, when associated with a link, it takes the user to the associated document.  <A accesskey="C" href="doc.html">Press C to go to XYZ page</A>

For more information:

  1. Links - Chapter 12 in the Central Reference Document
  2. Links - the HTML 4.0 specification

7. Frames

  1. [Required]
      Ensure that pages are readable and usable without frames.
    [New] Authors should include a NOFRAMES element at the end of each FRAMESET. Please refer to the example in the Central Reference Document.

  2. [Required]
    Do not include an image directly in a frame -- put it in a separate document.
    [New] Otherwise, if the frame contents change, the frame title -- the only alternative text available in this case -- will no longer make sense. Including the image in its own file allows authors to specify alt-text with the IMG or OBJECT elements.

  3. [Required]
      Give each frame a title.
    [New] People accessing the page aurally will more easily keep track of how many frames exist and which is the current one. For 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>
    
  4. [Recommended]
    Describe the layout and purpose of frames and how multiple frames relate to each other.
    [New] Use the "longdesc" attribute on the FRAME and IFRAME elements to designate a long description.

For more information:

  1. Frames - Chapter 16 in the Central Reference Document
  2. Frames - the HTML 4.0 specification

8. User-Input Forms

  1. [Required]
      Do not use image maps to create graphical "submit" buttons.
    Instead, use the BUTTON or INPUT elements with alternative text.

  2. [Required]
      Associate labels with their controls explicitly.
    [New] The "for" attribute of the LABEL element allows explicit association. For example:
    <FORM action="http://somesite.com/adduser" method="post"
    <FIELDSET>
    <LEGEND>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>Medical History</LEGEND>
    ...medical history information...
    </FIELDSET>
    </FORM>
    
  3. [Required]
      Provide alternative text for images used as "submit" buttons.
    For example: <INPUT type="image" name="submit" src="button.gif" alt="Submit">

  4. [Recommended]
      Specify a logical tab order among form controls.
    [New] The "tabindex" attribute specifies the tabbing navigation order among form controls. For example:
    <INPUT tabindex="1" type="text" name="field1">
    <INPUT tabindex="2" type="text" name="field2">
    <INPUT tabindex="3" type="submit" name="submit">
    
  5. [Recommended]
      Group related controls semantically and label each group.
    [New] The new FIELDSET element groups form controls while the LEGEND element labels each group. Please see the example in guideline 10.2.

  6. [Recommended]
    For long lists of selections, group items into a hierarchy.
    [New] In the near future, browsers will display grouped lists with expanding and collapsing levels of detail.   To group items, use the OPTGROUP element (with the SELECT element). For 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>
    
  7. [Recommended]
      Include default, place-holding characters in edit boxes and text areas. [Interim]

  8. Recommended]
      Include a phone number, fax number, e-mail address, or postal address as alternate an way to submit information. [Interim]

  9. [Recommended]
      Furnish keyboard shortcuts for form elements.
    [New] Keyboard shortcuts are assigned with the "accesskey" attribute. This example assigns "U" as the access key. Typing "U" gives focus to the label which gives focus to the control then the user can input text.
    <FORM action="submit" method="post">
    <LABEL for="user" accesskey="U">user name</label>
    <INPUT type="text" name="user">
    </FORM>
    

For more information:

  1. Forms - Chapter 17 in the Central Reference Document
  2. Forms - the HTML 4.0 specification

9.  If All Else Fails...

If, after best efforts, any page is still not accessible, provide a link to an alternative page which is accessible, has equivalent information, and is maintained with the same frequency as the inaccessible page.  Alternative pages are not a recommended practice because maintenance costs increase the likelihood that the alternative pages will become outdated.  If alternative pages are created they must be updated as frequently as the main pages and provide equivalent information.

  1. Methods for linking to alternative pages:
    1. [Interim] Provide a visible link at the top of each page to allow a user to move back and forth between the graphic and alternative versions of the page.
    2. [New] Provide the appropriate information in the header of the principal page (with the LINK element) so that the browser loads it automatically. If the user has set their default media type to "aural," "braille," or "tty"  the user agent should load the alternative page automatically.  For 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>
      

10. Good Web Site Design Practices

Following the general site design guidelines will further improve accessibility.

  1. Create a consistent style for pages.
  2. Use a clear, consistent navigation structure.
  3. Offer navigation bars for easy access to the navigation structure.
  4. Provide a description of the general layout of the site, the access features used, and how to use them.
  5. Offer a site map.
  6. Offer different types of searches for different skill levels and preferences.
  7. Ensure that nothing within the site prevents keyboard operation.
  8. Ensure that text and background colors or patterns contrast well.   (A good test is to print your page to a black and white printer).
  9. Use a design tool that supports access features (and does not remove access when you close, or reopen your page using the tool).
  10. Place distinguishing information at the beginning of headings, paragraphs, lists, etc., to decrease the amount of sifting readers perform to find important information.  This is commonly referred to as "front-loading" and is especially helpful for people accessing information serially.
  11. Create a single downloadable file for documents that exist as a series of separate pages. This helps people reading documents off-line.  Currently, an archival or compression program is needed to create the single file.  In the near future, user agents will be able to collate separate pages based on information  in page headers.  The following example shows how to indicate where the first page of the reference manual exists as well as  which page follows the current one.
    <HEAD><TITLE>Reference manual -- Chapter 1</TITLE>
       <LINK rel="Start" title="The first page of the manual"
             type="text/html" 
             href="http://someplace.com/manual/start.html">
       <LINK rel="Next" title="Chapter 2" 
             type="text/html" 
             href="http://someplace.com/manual/ch2.html">
    </HEAD>
  12. Test the site with at least:
  13. It may also be helpful to test a site with a self-voicing browser (such as PWWebspeak)
  14. Validate pages with tools such as:

For more information:

Good Web Site Design Practices - Chapter 25 in the Central Reference Document


Appendix A - Table examples

  1. "headers" - The following example shows how to associate header information with 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".
    
    <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 by speaking the following:

               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
            
  2. "scope" - The following example associates the same header and data information as the previous example, but 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. This example might be rendered by a speech synthesizer as the previous example.
    
    <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 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>
    
  3. "axis" - The following example shows how to create categories within a table.
    
    <TABLE border="border">
    <CAPTION> Travel Expense Report </CAPTION>
    <TR>
    <TH></TH>
    <TH id="a2" axis="expenses">Meals</TH>
    <TH id="a3" axis="expenses">Hotels</TH>
    <TH id="a4"
    axis="expenses">Transport</TH><TD>subtotals</ TD>
    </TR>
    <TR>
    <TH id="a6" axis="location">San Jose</TH>
    <TH></TH><TH></TH><TH></TH><TD> </TD>
    </TR>
    <TR>
    <TD id="a7" axis="date">25-Aug-97</TD>
    <TD headers="a6 a7 a2">37.74</TD>
    <TD headers="a6 a7 a3">112.00</TD>
    <TD headers="a6 a7 a4">45.00</TD><TD></TD>
    </TR>
    <TR>
    <TD id="a8" axis="date">26-Aug-97</TD>
    <TD headers="a6 a8 a2">27.28</TD>
    <TD headers="a6 a8 a3">112.00</TD>
    <TD headers="a6 a8 a4">45.00</TD><TD></TD>
    </TR>
    <TR>
    <TD>subtotals</TD><TD>65.02</TD><TD>224.00&
    </TD><TD>90.00</TD><TD>379.02</TD>
    </TR>
    <TR>
    <TH id="a10" axis="location">Seattle</TH>
    <TH></TH><TH></TH><TH></TH><TD> </TD>
    </TR>
    <TR>
    <TD id="a11" axis="date">27-Aug-97</TD>
    <TD headers="a10 a11 a2">96.25</TD>
    <TD headers="a10 a11 a3">109.00</TD>
    <TD headers="a10 a11 a4">36.00</TD><TD></TD>
    </TR>
    <TR>
    <TD id="a12" axis="date">28-Aug-97</TD>
    <TD headers="a10 a12 a2">35.00</TD>
    <TD headers="a10 a12 a3">109.00</TD>
    <TD headers="a10 a12 a4">36.00</TD><TD></TD>
    </TR>
    <TR>
    <TD>subtotals</TD><TD>131.25</TD><TD>218.00
    </TD><TD>72.00</TD><TD>421.25</TD>
    </TR>
    <TR>
    <TH>Totals</TH><TD>196.27</TD><TD>442.00
    </TD><TD>162.00</TD><TD>800.27</TD>
    </TR> 
    </TABLE>
    

Appendix B - Alt-text authoring guidelines

General recommendation

Perhaps a good test would be as follows:  if you were reading the document aloud over the telephone, what would you say upon encountering this image to make the page comprehensible to the listener?  Aim for a functional and contextualized label or description rather than a visual description. 

There are three attributes of IMG that can be used to provide textual information about an image:

Providing alternative text for images embedded with the OBJECT element is a different beast and will be covered in the future.

 

Decorative graphics

Provide a brief textual equivalent of the image. Providing alt-text is required while providing a longer description is recommended.
Example:  <img src="sailboats.gif" alt="Sailboats in calm water" longdesc="sailboatsdesc.html">
(within sailboatsdesc.html) A picture of ten sailboats docked in calm water at the edge of busy street in a small town.

Since some users may not want to see even a short description of the graphic, keep them as short as possible.  In the future, we will make recommendations for the use of style sheets, class values and xml that will allow users to select types of images they wish to download and view.

 

Bullets

  1. Mark up list items correctly
  2. For unordered lists where bullets do not provide additional information use "Item:" as the alt-text. Avoid using style sheets to provide alternative bullets until a way as been found to associate alt-text with the image (see Example 2).
    Example 1:  <!-- style UL { list-style: none }><UL> <LI><img src="star.gif" alt="Item:">Audrey</LI><LI><img src="star.gif" alt="Item:">Laurie</LI> ... </UL>
    Example 2: (Avoid) <!-- style UL { list-style: url(star.gif) }> <UL><LI> Audrey</LI><LI> Laurie</LI> ... </UL>
  3. For unordered lists where bullets do provide additional information, provide the label in the alt-text.
    Example: <!-- style UL { list-style: none }><UL><LI><img src="red.gif" alt="New:">Roth IRA</LI> <LI><img src="yellow.gif" alt="Old:">401 K</LI> ... </UL>
  4. For ordered lists, provide the item number in the alt-text
    Example:  <OL><LI><img src="bullet1.gif" alt="One:"></LI> ... </OL>

 

Buttons

Provide the equivalent textual link phrase in the alt-text  (i.e. if the link was text instead of graphical what would it say).
Example:  <a href="http://routes.html"><img src="topo.html" alt="Current routes at Boulders Climbing Gym"></a>

 

Section separators

For images used as section separators (horizontal rules) provide information about what the image represents.  In other words, provide an equivalent textual cue as to what the visual reader perceives.
Example: 
<img src="redline.gif" "End of Chapter 7 - Visual Displays">
<H1>Chapter 8 - Auditory and Tactile Displays</H1>

 

Bitmap text

If the image is simply a picture of stylized or colorful text, then the alt-text must be the same as the text in the image.  <P>This is an <IMG SRC="BigRedExample.gif" ALT="Example"> of what we mean.</P>

 

Invisible images used as spacers

Invisible or transparent images are often used to force the layout of a page.   Provide "null alt-text" in these instances.
Example:  <img src="spacer.gif" alt="">

 

Future notes

  1. Alternative text for images included with object is a backwards compatible solution but not consistent across newer browsers.
  2. We need to address issues created by using style sheets to include images for bullets in lists.
  3. As suggested earlier, future technologies, such as XML will allow authors to label objects and images as decorative, charts, bullets, etc.
  4. Predefined class types will also allow authors to attach literal values such as wallpaper, navigation bar, etc. to images and objects.  This will then allow users to select which types of predefined class types they want to see, which they would like descriptions for, or which they would like to ignore.  This can be controlled with personal style sheets.

HTML Author Checklist
W3C Working Draft    02-Feb-1998


Rating System

Each guideline may be accompanied by a rating that describes its importance:

[Required]
Required, otherwise it will be impossible for some groups of users to understand the page.
[Recommended]
Makes page easier to understand and use.

Style and Structure

  1. [Required]   All elements comply with the HTML 4.0 definition or current style sheet specification.
  2. [Required]   Pages are readable and usable without style sheets (e.g., when the browser does not support them or the user has turned them off).
  3. [Required] Headings are nested properly and are not used for formatting.
  4. [Required] List structure and list items are correctly encoded with proper HTML elements.
  5. [Required] The BLINK and MARQUEE elements have not been used.
  6. [Recommended] Formatting is done with style sheets rather than converting text to images.
  7. [Recommended] Invisible or transparent images are not used to force layout. Style sheets are used to control layout.
  8. [Recommended] Deprecated presentation elements (TT, ALIGN, BORDER, FONT and BACKGROUND) as well as B and I are not used.
  9. [Recommended] HTML structural elements are only used to convey meaning, not presentation.
  10. [Recommended] HTML presentation elements are only used to convey presentation, not structure.
  11. [Recommended] Horizontal rules, acronyms, and abbreviations have titles.

Images and Image maps

  1. [Required] All images and image maps have alternative text.
  2. [Required] Graphics that present important information (especially charts, tables, and diagrams) have an associated longer description of the graphic (i.e., via a description link or the " longdesc" attribute) Furthermore, authors have included internal text in images for formats that support it.
  3. [Required] Client-side image maps have been designed instead of server-side image maps. Furthermore:
    • For each client-side image map, each of the map's links has an associated description.
    • For each server-side image map, a list of the map's links are provided as text links (on the same page, on an alternative page that is accessible, or within the body of the OBJECT element).
  4. [Recommended] All images used as links have descriptive link titles.
  5. [Recommended] All ASCII art has been replaced by images with alternative text.

Applets and Scripts

  1. [Required] All scripts have a non-script alternative (the NOSCRIPT element).
  2. [Required] The user can freeze any moving or blinking text.
  3. [Required] All applets have alternative text.
  4. [Required] Descriptions are provided for applets that convey important information.
  5. [Required] Alternative mechanisms (e.g., a form) are provided for applets that gather information .
  6. [Required] Applets that require user interaction that cannot be duplicated in an alternative format are directly accessible.
  7. [Recommended] Alternative, accessible presentations of information are provided for applets embedded with the OBJECT element.
  8. [Recommended] Scripts and applets are keyboard operable (TBD)

Audio and Video

  1. [Required] All audio information has an associated transcript.
  2. [Required] All video information has an associated audio description.
  3. [Required] All video information has an associated transcript.
  4. [Required] Transcripts and audio descriptions are synchronized with audio/video information, either directly or via a synchronization file.
  5. [Recommended] Links to very short sounds have titles.

Tables

  1. [Required] Table cells are explicitly associated with row and column labels.
  2. [Required] Tables are not used to arrange text documents in columns.
  3. [Recommended] Tables are not used merely for the purposes of page layout (use style sheets instead).
  4. [Recommended] Tables of text and numbers are available in a linear fashion on an alternative page.
  5. [Recommended] Lengthy row and column labels are abbreviated.
  6. [Recommended] Table summaries are available.
  7. [Recommended] For more complex tables, information is grouped into categories.
  8. [Recommended] Alt-text does not wrap in tables used to position graphics.
  9. [Recommended] A phone number, fax number, or e-mail address is provided if tables can not be made accessible.

Links

  1. [Recommended] Link text makes sense when read out of context, but is not too verbose.
  2. [Recommended] Lists of links have non-link, printable characters (surrounded by spaces) between them.
  3. [Recommended] Links have keyboard shortcuts.

Frames

  1. [Required] Each frame document (the FRAMESET element) has a non-frame alternative (e.g., the NOFRAME element).
  2. [Required] An image does not appear directly in a frame but is part of a document included in a frame.
  3. [Required] All frames have titles.
  4. [Recommended] Links to descriptions of the purpose and layout of frames are provided.

User-Input Forms

  1. [Required] Image maps are not used to create graphical "submit" buttons.
  2. [Required] Each label is explicitly associated with its control.
  3. [Required] Images used as "submit" buttons have alternative text.
  4. [Recommended] A logical tab order is specified (with the "tabindex" attribute).
  5. [Recommended] Related controls are grouped (with the FIELDSET element).
  6. [Recommended] Groups of controls are labeled (with the LEGEND element).
  7. [Recommended] Menu options are grouped (with the OPTGROUP element).
  8. [Recommended] Edit boxes and text areas have default, place-holding characters.
  9. [Recommended] An alternative phone number, fax number, e-mail address, or postal mail address is provided for submitting information.
  10. [Recommended] Form elements have keyboard shortcuts (with the "accesskey" attribute).

If All Else Fails...

If after best efforts, a page is still not accessible, provide a link to an alternative page that is accessible, has equivalent information, and is maintained with the same frequency as the inaccessible page.

Good Web Site Design Practices

  1. Lay out pages with a consistent style.
  2. Use a clear, consistent navigation structure and provide access to that structure with navigation bars.
  3. Provide a description of the general layout of the site, the access features used, and how to use them.
  4. Offer a site map.
  5. Offer different types of searches for different skill levels and preferences.
  6. Ensure that nothing within the site prevents keyboard operation.
  7. Ensure that text and background colors or patterns contrast well.   (A good test is to print your page to a black and white printer).
  8. Use a design tool that supports access features (and does not remove access when you close or reopen your page using the tool)
  9. Place distinguishing information at the beginning of headings, paragraphs, lists, etc., to decrease the amount of sifting readers perform to find important information.
  10. Create a single downloadable file for documents that exist as a series of separate pages.
  11. Test the accessibility of the site by browsing pages with at least:
    • a text only browser (e.g., Lynx or a Lynx emulator such as Lynx Viewer or Lynx-me)
    • multiple graphic browsers, with:
      • sounds and graphics loaded,
      • graphics not loaded,
      • sounds not loaded,
      • no mouse
  12. It may also be helpful to test a site with a self-voicing browser (such as PWWebspeak)
  13. Validate pages with tools such as:

Acknowledgements

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

HTML 4.0 Recommendations.

Designing Accessible Web Pages -- guidelines and overview documents

  1. Accessible Design for Users with Disabilities. -- Sun Microsystems
  2. The Accessible Web: Web Access Through Adaptive Technology -- Kevin Nguyen, University of Toronto
  3. Accommodating Imperfection -- All Things Web
  4. ALT text recommendations, and notes on viewing situation -- A.J. Flavell, University of Glasgow
  5. Alternative Access to the World Wide Web -- University of Toronto
  6. Any Browser Table Format -- Department of Missions, Abilene Christian University
  7. Best Viewed With Any Browser -- Accessible Site Design
  8. Compatibility & Accessibility -- Towards the creation of an accessible, truly World-wide Web -- All Things Web
  9. Composing Good HTML -- James "Eric" Tilton.
  10. Design Considerations: Readers with Visual Impairments -- Arthur R. Murphy
  11. Designing Access to WWW Pages - Alliance for Technology Access.
  12. Designing HTML Tables to Work with HTML 2.0 Browsers -- Stanton McCandlish
  13. DO-IT HTML Guidelines -- University of Washington
  14. Experiences Implementing Web Accessibility Guidelines in IBM -- Phill Jenkins
  15. For Web Page Designers -- Microsoft
  16. GSA HTML Accessibility Guidelines -- Paul Fontaine
  17. Guide to Writing Accessible HTML -- University of Toronto
  18. Hints for designing accessible Websites -- Royal National Institute for the Blind
  19. IBM Web Design Guidelines  -- IBM Human Computer Interaction (HCI)
  20. IBM Guidelines for Writing Accessible Applications Using 100% Pure Java -- IBM Special Needs Systems
  21. Increasing Access to World Wide Web Sites for Blind and Visually Impaired Computer Users -- Dena Shumila, Jan Richards
  22. InfoUse Web Accessibility Guidelines -- Jane Berliss, Lewis Kraus, Susan Stoddard
  23. LEVELLING THE ROAD AHEAD: GUIDELINES FOR THE CREATION OF WWW PAGES ACCESSIBLE TO BLIND AND VISUALLY HANDICAPPED USERS, Judith M. Dixon, Ph.D., Consumer Relations Officer, National Library Service for the Blind and Physically Handicapped
  24. The Lynx Manifesto -- Dehanced for Lynx
  25. Making Your Site Speech Friendly -- Cathy Anne Murtha, Web Design and Access Specialist, Magical Mist Creations
  26. NCSA Mosaic Access Page
  27. Nimble Document Navigation Using Alternative Access Tools -- Jutta Treviranus, University of Toronto
  28. Starling Access Services Accessible Web Page Design -- Chuck Letourneau
  29. Tables on non-table browsers -- A.J. Flavell, Glasgow University
  30. Unified HTML Accessibility Guidelines -- Previous version of this document
  31. Universal Accessibility -- Government of Canada Internet Guide
  32. Universal Design of WWW Pages -- a DO-IT (University of Washington) Brochure
  33. Universal Information Access on the WWW (COCA)
  34. "Universal Specifications" Accessibility Standards for Web Design -- New South Wales Attorney General's Department
  35. Usability of Information and the WWW -- UCLA Disabilities and Computing Program
  36. IBM Web Accessibility Guidelines -- IBM Special Needs Systems
  37. World Wide Web Access: Disability Discrimination Act Advisory Notes -- Australia