WAI-PAGEAUTH-0130

WAI Accessibility Guidelines: Page Authoring

[Not yet a] W3C Working Draft     30-Jan-1998

Working Group Chairs:
Chuck Letourneau, Starling Software
Gregg Vanderheiden, Trace Research and Development

Editors:
Gregg Vanderheiden, Trace Research and Development
Wendy Chisholm, Trace Research and Development
Ian Jacobs, W3C

Contributors:
Jim Bell, Jane Berliss, Harvey Bingham, Judy Brewer, Kevin Carey, John Churchill, David Clark, Dan Connolly, Daniel Dardailler, Judith Dixon, Martin Durst, Paul Fontaine, Geoff Freed, Alfred S. Gilman, Larry Goldberg, Jon Gunderson, Markku Hakkinen, Scott Isaacs, Scott Isensee, Jun Ishikawa, Steve Jacobs, Phill Jenkins, Alan Karben, Hiroshi Kawamura, George Kerscher,  Peter Korn, Josh Krieger, Chuck Letourneau, Edmund MacKenty, Murray Maloney, Aya Matsui, Gabriel Michel, Jim Miller, Masafumi Nakane, Charles Oppermann, Mike Paciello, David Pawson, Michael Pieper, Dave Raggett, T.V. Raman, Jan Richards, Madeleine Rothberg, Jutta Treviranus, Steve Tyler, Jaap Van Lelieveld,  Jason White, Tom Wlodkowski, ATRC, CAST, InfoUse, NCR, WGBH, WINGS, YRIF, and the WAI IG and GL Working groups

W3C staff contacts:
Judy Brewer and Daniel Dardailler

This version is:

http://www.w3.org/WAI/GL/WD-WAI-PAGEAUTH-0130

Latest version:

http://www.w3.org/WAI/GL/WD-WAI-PAGEAUTH

Previous versions:

http://www.w3.org/WAI/GL/WD-WAI-HAG-0123

http://www.w3.org/GL/htmlgide.htm

Status of this document

This is [not yet] 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 DOM 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 authors of this document are the WAI GL members.

The goal of the WAI-GL group is discussed in our charter.

We will update this draft specification on a regular basis.

Comments

Please send detailed comments on this document to w3c-wai-gl@w3.org.   Public discussion about the WAI author guidelines also takes place on this mailing list.

Rating and Classification

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

[Required]

Required for some groups of users to access the information on a 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 earlier versions of HTML and old or new browsers.

1. Style Sheets

[New] Style sheets are supported as of HTML 4.0.

1. [Required]  
     Ensure that your pages are readable and usable without style sheets (e.g. when the browser does not support or the user prefers not to load).  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.
   
2. [Recommended]
     Use style sheets to control colors, fonts, and the position of text, images, and objects, instead of HTML markup.

   Use style sheets instead of elements (such as I, B, FONT, etc.) and attributes (such as "align") that control visual presentation. Authors should continue to use elements (such as STRONG, EM, H1, H2, ABBR, etc.) that add structure to documents.

   Use style sheets rather than:

   • converting text to images or alternative text file formats (such as PDF)
   • using tables or PRE elements to layout pages
   • using proprietary extensions
   • using "invisible" images to layout pages
   • writing a program to accomplish something that is possible with style sheets or plain HTML

   Use style sheets to:

   • position text and graphics
   • create drop caps, subscripts and superscripts
   • avoid uncommon typographic characters or constructions (such as ASCII art, etc.)
   • create alternative versions of a page. Whether or not you anticipate your page being viewed on alternative media, such as a PDA, a speech-based browser or paper (printed), it is a good idea to create style sheets for alternative media to facilitate readability.   Example media types are screen, tty, tv, projection, handheld, print, braille, aural, and all.
   • highlight sections of a document with font size, formatting or color.

For more information:

1. Style Sheets - Chapter 14 in the Central Reference Document
2. Style Sheets - the HTML 4.0 specification
3. Draft recommendation for Cascading Style Sheets (CSS-2) from the World Wide Web Consortium

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 describes the function of the graphic. Examples of possible alt-text are, "Section Title: Banana Products," "Graph of population versus age," or "Search Button."  Possible strategies include:
   1. The "alt" attribute is mandatory for the AREA and IMG elements, but should also be used for APPLET, and INPUT. For example, <IMG src="logo.gif" alt="XYZ Logo">.
   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>
   3. Include internal text in image file formats that support it.
2. [Required]  
     Provide a link to a longer description for graphics that present important information (especially charts, tables and diagrams).
   Alternative text descriptions (strategy 2.1) are usually short and define the basic purpose of graphic elements. To describe the graphic itself in more detail a link to a longer description should be provided, by one of the following mechanisms:
   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>
3. [Required]  
     Use client-side (instead of server-side) image maps.
   In terms of accessibility, client-side image maps are similar to server-side image maps except that client-side image maps allow immediate feedback as to whether or not the user's pointer is over a "hot-spot". Non-visual browsers can render "alt" or "title" attribute values provided with the URLs rather than the images.

   If a server-side image map has to be used, provide a list of the image map choices (links) as text links on the same page, on an alternative page that is accessible, or within the body of the OBJECT element (similar to strategy 2.4.2). To avoid confusion, if providing the list of links following the image map, you should indicate within the alt-text of the image map that this is an alternate list.

4. [Required]  
     Provide a description for each link in an image map.
   Depending on how you've created your image map you have 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 coords="0,0,30,30" href="reference.html" alt="Reference">
      <AREA coords="34,34,100,100" href="media.html"
      alt="Audio Visual lab">
      </MAP>
      

      [New] The same idea, this time with the OBJECT element:

      <OBJECT data="welcome.gif" usemap="#map1">
      alt="Image map of areas in the library"
      </OBJECT>
      <MAP name="map1">
      <AREA coords="0,0,30,30" href="ref.html"alt="Reference">
      <AREA coords="34,34,100,100" href="media.html" 
      alt="Audio Visual Lab">
      </MAP>

   2. [New] If the MAP element is used with A elements that specify active region geometries, set the "title" attribute of each A element.

      <OBJECT data="navbar1.gif" type="image/gif" usemap="#map1">
      <MAP name="map1">
      <P>Navigate the site:
       <A title="Access Guide"href="guide.html" 
          shape="rect" coords="0,0,118,28">Access Guide</a> |
       <A title="Go" href="shortcut.html" 
          shape="rect" coords="118,0,184,28">Go</A> |
       <A title="Search" href="search.html" 
          shape="circle" coords="184,200,60">Search</A> |
       <A title="Top 10" 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 (e.g., a graphical button). For example:

   <A href="home.html" title="XYZ company home page">
   <IMG src="logo.gif" alt="XYZ logo">
   </A>

6. [Recommended]  
     Avoid using ASCII art or replace it with an image and alternative text.
   Common typographic characters or constructions to be avoided are emoticons, arrows consisting of dashes and greater than signs -->, 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 exercise -->
      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 to gather 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. [View the example.]
   
   
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. Audio and Video

1. [Required]
     Provide a text transcript of all audio information.
   A transcript is a textual representation of all dialogue, and audio information.
   
   
2. [Required]
     Provide descriptions of all video information in an auditory form synchronized with the audio track.
   
   
3. [Required]
     Provide descriptions of all video information in a text format.
   A text transcript of video action provides the same information as in recommendation 4.2, but in a text format.
   
   
4. [Required]
     Synchronize transcript 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 you are using 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 semantic information instead of the auditory if the user preferences are set to do so. However, how do we resolve this so it will 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"></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

5. Text, Symbols, Punctuation, Phrases, and Paragraphs

Please refer to the section on style sheets for more information about formatting and positioning text and graphics.

1. [Required]
     Use elements and attributes that convey structure rather than presentation.
   Structural elements include: ABBR, ACRONYM, CITE, CODE, DFN, EM, H1, H2, KBD, SAMP, STRONG, VAR, etc.
   Presentation elements include: size="14", B, I, TT, FONT, BASEFONT, CENTER.
   Removing style elements and attributes from HTML in favor of style sheets allows users to adjust the look of the screen (e.g., larger print, color contrast, etc.) when they apply their own style sheets or for browsers to adjust the presentation of the document based on user settings. Logical elements, on the other hand, enforce consistency in your documents and leave open the possibility for more sophisticated uses of the semantic encodings (e.g., indexing, search engines, programs that extract tables to databases, etc.). Some browsers use header elements (H1, H2, etc.) to generate navigation tools.
   
2. [Required]
     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.
   
3. [Required]
     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="Rule introducing navigation bar">
   [ <A rel="Next" href="next.html">Next page alt="Next page"</A> |
     <A rel="Previous" href="previous.html">Previous page alt="Previous page"</A> |
     <A rel="First" href="first.html">First page alt="First page"</A> ]
   </DIV>
   

4. [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.
   
   
5. [Required] 
     Nest headings properly.
   [New] Proper nesting of heading is important for document navigations.   Authors should use style sheets, not headings (that might cause presentational side effects), for formatting.
   
6. [Recommended]
     Title horizontal rules, acronyms and abbreviations. 
   For example,
   <HR title="new section">
<ABBR>title="World Wide Web">WWW</ABBR>

Tips and Tricks

• To test if the text and background contrast is sufficient enough to be read by people with color deficiencies or on low resolution monitors, view your pages with a monochrome monitor.
  
  
• To get a better understanding of what a screen reader would present to a user, do not load the images on a page when viewing with a graphical browser or use a text-based browser such as Lynx.

For more information:

1. Text - Chapter 9 in the Central Reference Document
2. Text - the HTML 4.0 specification

6. Lists and Outlining

1. [Required] 
     Encode list structure and list items properly.
   The HTML list elements (DL, UL, OL, LI) should be used to create lists, not for presentation (e.g., indentation).

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

Tips and Tricks

• Using a numbered (ordered) list makes it easier for people accessing the page aurally to keep track of where they are within a list.

For more information:

1. Lists and Outlining - Chapter 10 in the Central Reference Document
2. Lists - the HTML 4.0 specification

7. 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.
   [Interim] Please consult the section on linking to alternative pages.
   
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] 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) 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

• To predict how one of today's screen readers might read your table, hold a piece of paper up to your monitor.  As you slide the paper down the monitor,  read the words above the line the paper creates as a sentence.  Ask another person to listen as you read the page out loud without pausing for column gaps.  Can he or she make sense out of what you have read?
  
  
• Another method, to predict how a screen reader will interpret your page, is to save it as a text-only file then open it with a word processing program.  This function is available in the "File" menu in most browsers.

For more information:

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

8. 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).
   A user should be able to select a link from a list of all of the links on a page without reading the context in which the link was used. For example, don't use "click here" as the text phrase for several links since this requires a user browsing the page with a screen reader to scout out each link to determine the context before selecting one. Instead, supply something like "download this document in ASCII text," "view the full version in HTML," or "select to view the text version."
   
   
2. [Recommended]
     Place non-link,  printable characters (surrounded by spaces)  between links which occur consecutively to keep separate links from being read as one by screen readers.
   [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>

4. 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 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"  this will load the alternative page automatically.  For example:

      <HEAD>
      <TITLE>This document has a text-only version</TITLE>
      <LINK title="Text-only version"
            rel="alternate" href="text_only.html"
            media="aural, braille, tty">
      </HEAD>
      

For more information:

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

9. Frames - Multi-view presentation of documents

1. [Required]
     Ensure that your 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 alternate 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">
   </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

10. 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 attribute provides 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.
   
8. [Recommended]
     Include a phone number, fax number, e-mail address, or postal address as alternate ways to submit information. 
   
9. [Recommended]
     Create 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

11.  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.  This is a last resort since it increases site maintenance.

12. 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. Do not use elements outside of the HTML 4.0 specification (such as <BLINK> and <MARQUEE>).
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 facilitates 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:
    • a text only browser (such as 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
13. It may also be helpful to test your site with a self-voicing browser (such as PWWebspeak)
14. Validate your pages with tools such as Bobby  http://www.cast.org/bobby/, W3C HTML Validation Service http://validator.w3.org/ , or Kinder-Gentler Validation  http://ugweb.cs.ualberta.ca/%7Egerald/validate/

For more information:

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

Appendix

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

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.

   <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&
   lt;/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>
   

HTML Author Checklist
W3C Working Draft    30-Jan-1998

Rating System

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

[Required]

Required for some groups of users to access the information on a page.

[Recommended]

Makes page easier to understand and use.

Style Sheets

Images and Image maps

Applets and Scripts

Audio and Video

Text, Symbols, Punctuation, Phrases, and Paragraphs

Lists and Outlining

Tables

Links

Frames

User-Input Forms

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