ADVANCED DRAFT COPY

ADVANCED DRAFT COPY

Unified Web Site Accessibility Guidelines

December 1, 1997

Compiled by:
Gregg C. Vanderheiden Ph.D., Wendy A. Chisholm, M.S.,
Trace R and D Center, University of Wisconsin - Madison
For the Web Accessibility Initiative Guidelines Working Group

Three versions of this document currently exist as part of the
Advanced Draft Copy:

Page Author Check List

Page Author Guidelines

The Master Document

----------
ADVANCED DRAFT COPY

Page Author Check List - Version 8
Unified Web Site Accessibility Guidelines


Rating System

     [Required] - Required for some groups of users to
     access the information on a page.
     [Recommended] - Makes page easier to understand and
     use.


Style Sheets

  * [_] Positioning and formatting are done with style sheets,
    not within the text (e.g. <B> or the "align" attribute of
    <IMG>) (However, continue to use logical elements such as
    STRONG, H1, etc.  to provide semantic coding within the body
    of the page) [Required]
  * [_] Pages are readable and usable without style sheets (e.g.
    when the browser does not support or the user prefers not to
    load). [Required]

Images and Image maps

  * [_] All images and image maps have alternative text.
    [Required]
  * [_] Graphics that present important information (especially
    charts, tables, and diagrams) have a longer description of
    the graphic that is available (i.e., via D-link or
    "longdesc," etc.) (Include internal text in image file
    formats that support it). [Required]
  * [_] Image maps are client-side image maps AND each link
    within it has a description.
    -- OR --
    A list of the (server-side) image map choices (links) are
    provided as text links (i.e. on the same page, on an
    alternative page that is accessible, or within the body of
    the <OBJECT> element). [Required]
  * [_] All images used as links have descriptive titles.
    [Recommended]

Applets and Scripts

  * [_] All scripts have a <NOSCRIPT> option. [Required]
  * [_] The user can freeze any moving or blinking text.
    [Required]
  * [_] All applets have alternative text. [Required]
  * [_] Descriptions are provided for applets that convey
    important information. [Required]
  * [_] Applets that gather information have alternative
    mechanisms to gather the information (e.g. an HTML form).
    [Required]
  * [_] Applets that require a user interaction (e.g. the
    ability to manipulate a physics experiment) that can not be
    duplicated in an alternative format, are directly
    accessible. [Required]
  * [_] Alternative, accessible presentations of information are
    provided for applets embedded with the <OBJECT> element.
    [Recommended]
  * [_] Scripts and applets are keyboard operable ( using
    standard conventions). [Recommended]

Audio and Video

  * [_] All information presented auditorally is available in a
    text transcript file. [Required]
  * [_] All video information is described and available in an
    auditory form. [Required]
  * [_] Video descriptions are also available in a separate text
    transcript file. [Required]
  * [_] Transcript and video description information is
    synchronized with audio/video information, either directly
    or via a synchronization file. [Required]

Text - Paragraphs, Horizontal Lines, Phrases, Punctuation and
Symbols

  * [_] Logical styles are used (correctly) rather than physical
    markups. [Recommended]
  * [_] The <BLINK> and <MARQUEE> elements have not been used.
    [Recommended]
  * [_] Headings are nested properly. Style sheets are used for
    formatting. [Recommended]

Lists and Outlining

  * [_] List structure and list items are correctly encoded with
    proper HTML elements (UL, OL, LI). Use style sheets to
    adjust item spacing. [Recommended]

Tables

  * [_] Table cells are explicitly associated with row and
    column labels.  [Required]
  * [_] Tables or <PRE> elements are not used to arrange text
    documents in columns or otherwise layout a page. [Required]
  * [_] Lengthy row and column labels are abbreviated.
    [Recommended]
  * [_] Table summaries are available. [Recommended]
  * [_] For more complex tables, information is grouped into
    categories.  [Recommended]
  * [_] Alt-text does not wrap in tables used to position
    graphics. [Recommended]   [how to verify??]
  * [_] Tables of text and numbers are available in a linear
    fashion on an alternative page.   [TBD]
  * [_] A phone or fax number or e-mail address is provided if
    tables can not be made accessible. [Recommended]

Links

  * [_] Link phrases make sense when read out of context (but
    they are not too verbose). [Recommended]
  * [_] Lists of links have non-link, printable characters
    (surrounded by spaces)  between them. [Recommended]

Frames

  * [_] Each <FRAMESET> has a <NOFRAME> option. [Required]
  * [_] All frames are titled. [Recommended]

User-Input Forms

  * [_] Image maps are not used to create graphical "submit"
    buttons. Required
  * [_] Labels are explicitly associated with their control.
    Required
  * [_] Images used as "submit" buttons have alternative text.
    Required
  * [_] A logical tab order is specified with "tabindex."
    [Recommended]
  * [_] Related controls are grouped with the <FIELDSET>
    element. [Recommended]
  * [_] Groups of controls are labeled using the <LEGEND>
    element. [Recommended]
  * [_] Edit boxes and text areas have default, place holding
    characters. [Recommended]
  * [_] A phone number, e-mail address, postal mail address or
    fax number is provided for submitting information.
    [Recommended]
  * [_] Form elements have keyboard shortcuts. [Recommended]

Tips and tricks to further enhance the usability of pages

  * 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.
  * Use the "title" attribute on horizontal rules <hr title="new
    section">, acronyms and abbreviations <abbr>title="World
    wide web">WWW</abbr>, and very short sounds <a
    href="mittens.wav" title="meow"></a>
  * Replace ASCII art with an image and alternative text.
  * Provide keyboard shortcuts for links.
  * Front-load link phrases in lists.

Good Web Site Design Practices

  * Page layout is consistent but pages or areas do not look
    identical.
  * A clear, consistent navigation structure is used.
  * Navigation bars provide easy access to the navigation
    structure.
  * Instructions are provided to describe the general layout of
    the site, the access features used, and how to use them.
  * A site map is available.
  * Different types of searches are available for different
    skill levels and preferences.
  * Nothing within the site prevents keyboard operation.
  * Elements outside of the HTML 4.0 specification (such as
    <BLINK> and <MARQUEE>) are not used
  * Use a design tool that supports access features (and does
    not remove access when you close, or reopen your page using
    the tool)
  * Test the site with AT LEAST:
    * a text only browser (such as Lynx)
    * a self-voicing browser (such as PWWebspeak)
    * Multiple graphic browsers, with:
      * sounds and graphics loaded,
      * graphics not loaded,
      * sounds not loaded,
      * no mouse

----------
ADVANCED DRAFT COPY

Page Author Guidelines - Version 8
Unified Web Site Accessibility Guidelines

December 1, 1997

Compiled by:
Gregg C. Vanderheiden Ph.D., Wendy A. Chisholm, M.S.,
Trace R and D Center, University of Wisconsin - Madison
For the Web Accessibility Initiative Guidelines Working Group

(This is a final Trace Center Guidelines Document.
It is compiled in preparation for transfer of the Guidelines to
the Web Accessibility Initiative of the W3C.
This guideline reflects recent work of the WAI as well as
previous contributions of many other guidelines developers
(listed in the master appendix)).   Contributors include: 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 Ragget, 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

(If you have contributed and your name or organization is
missing from the above list, inform us via e-mail so that we may
correct our omission - and we apologize in advance.)

Prepared under funding from
the National Institute on Disability and Rehabilitation Research
(NIDRR),
Office of Special Education and Rehabilitation Services (OSERS),
US Department of Education
The US Postal Service's WINGS project and
the NCSA-PACI Universal Design / Disability Access Project.

(This is a living document. Comments and suggestions are
solicited.)


 Rating System

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

     [Recommended] - Makes page easier to understand and
     use.

Classification System

     [Interim] - Strategies needed to make pages accessible
     for today's browsers and assistive technologies

     [New] - Strategies that will take advantage of new
     features being incorporated into supported tomorrow's
     browsers and assistive technologies (which incorporate
     Web Access Initiative recommendations).

     If a recommendation has several possible strategies,
     the strategies are classified, if not the
     recommendation itself is classified.  Those
     recommendations and strategies that have no
     classification work for both old and new browsers.


Style Sheets - Controlling the presentation of an HTML document

  * [Required]
      Use style sheets to position text and objects within
    pages, rather than physically marking up text and graphics
    (e.g. <B> or the "align" attribute of <IMG>) (However,
    continue to use logical elements such as STRONG, H1, etc.
    to provide semantic coding within the body of the page)
    [New]

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, print, projection, braille, and speech.
    * highlight sections of a document with font size,
      formatting or color

  * [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.


Images and Image maps

  * [Required]
      Provide alternative text for all images and image maps.
    All images 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 solution
    strategies include:
    * 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">.
    * [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>

  * [Required]
      Provide a link to a longer description (i.e., via D-link,
    or longdesc, etc.) for graphics that present important
    information (especially charts, tables and diagrams).
    (Include internal text in image file formats that support
    it).
    Alternative text descriptions (recommendation #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.
    * [Interim] Provide a 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>
    * [New] Use the "longdesc" attribute of the <IMG> element or
      provide text within the body of the <OBJECT > element. For
      example, <IMG SRC="97sales.gif" alt="Sales for 1997"
      longdesc="sales.html">

  * [Required]
      Use client-side (instead of server-side) image maps.
    Client-side image maps are similar to server-side image maps
    except that the information for all of the "hot-spots"
    within the image are sent to the browser along with the
    image map picture. Descriptions provided with the URLs can
    be displayed rather than the graphic. If server-side image
    maps can not be avoided, see the 5th strategy of the next
    recommendation.

  * [Required]
      Provide a description for each link in an image map.
    Depending on how you've created your image map you have
    several possibilities:
    * Use the "alt" attribute of the <AREA> element (with the
      IMAGE, MAP and AREA elements)

     <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] Use the "alt" attribute of the <AREA> element (with
      the OBJECT, MAP and AREA elements)

     <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="reference.html"
     alt="Reference">
     <AREA coords="34,34,100,100" href="media.html"
     alt="Audio Visual lab">
     </MAP>

    * [New] Use the "title" attribute of the <A> element (with
      the OBJECT and SHAPES elements)

     <OBJECT data="welcome.gif" shapes>
     Areas in the library
     <A coord="0,0,30,30" href="reference.html"
     title="Reference">Reference</A>
     <A coords="34,34,100,100" href="media.html"
     title="Audio Visual lab">Audio Visual Lab</A>
     </OBJECT>

    * [New] Create a descriptive paragraph within the <OBJECT>
      element that includes the links (using the OBJECT and A
      elements)

     <OBJECT data="welcome.gif" shapes>
     There are several areas in the library  including <A
     coord="0,0,30,30" href="reference.html">Reference</A>
     and <A coords="34,34,100,100" href="media.html"> the
     Audio Visual Lab</A>.  More text can follow or precede.
     </OBJECT>

    * 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 method #4
      above). 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 so.

  * [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 (usually a graphical
    button). For example, <A HREF= "home.html" title="XYZ
    company home page"><IMG SRC="logo.gif" alt="XYZ logo"></A>


Applets and Scripts

  * [Required]
      Provide a <NOSCRIPT> option for all 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>

  * [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.

  * [Required]
      Provide alternative text for all applets.
    * [Interim] Use the "alt" attribute of the <APPLET> element,
      such as:

     <APPLET code="Press.class" width="500" height="500"
     alt="Java applet: how temperature affects pressure.">
     As temperature increases the molecules in the
     balloon...
     </APPLET>

    * [New] Use an alternative of the <OBJECT>element, such as:

     <OBJECT classid="Press.class" width="500" height="500"
     title="Java applet: how temperature affects pressure.">
     As temperature increases the molecules in the
     balloon...
     </OBJECT>

  * [Required]
      Provide descriptions of applets that present important
    information.
    * [Interim] Use the <APPLET> element to provide a
      description (see the previous example).  Complete text
      descriptions could be substituted for the "Hello World!"
      message.
    * [New] Use the <OBJECT> element (see the previous example).
       Complete text descriptions and other accessible objects
      (see recommendation #5) could be substituted for the
      "Hello World!" message.

  * [Required]
      If an applet gathers information, provide an alternative
    mechanism to gather the information.
    As with the previous two recommendations, an alternative
    such as a user-input form, e-mail address, phone or fax
    number could be provided within the alternative text of
    either the <APPLET> or <OBJECT> elements.

  * [Required]
      If an applet requires a user interaction (e.g. the ability
    to manipulate a physics experiment) that can not be
    duplicated in an alternative format, make the applet
    directly accessible.
    The guidelines for accomplishing this are included within
    the Java Accessibility project, and are not yet complete.

  * [Recommended]
      For applets embedded with the <OBJECT> element, provide
    alternative, accessible presentations of information within
    the <OBJECT> element body. [New]
    In HTML4.0 the <APPLET> element has been replaced by the
    <OBJECT> element. The <OBJECT> element supports nesting of
    objects for alternative  renderings. For example:

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

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

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


Audio and Video

  * [Required]
      Provide a text transcript file for all information
    presented auditorally.
    A transcript is a textual representation of all dialogue,
    and audio information.

  * [Required]
      Provide descriptions of all video information in an
    auditory form.
    Audio  descriptions of video action provide additional
    information during breaks in the dialogue of a movie about
    the actions that are occurring.

  * [Required]
      Provide a separate text transcript file of all video
    descriptions.
    A text transcript of video action provides the same
    information as in recommendation #2 but in a format
    accessible to those with no audio access.

  * [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.
    * [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.
    * [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.

  * TBD
      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 like 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.

  * Design Trick: Use the "TITLE" attribute to provide a brief
    description within the link to very short sounds.
    For example, <a href="mittens.wav" title="meow"></a>


Text - Paragraphs, Horizontal Lines, Phrases, Punctuation and
Symbols

  * Refer to the section about Style Sheets for information
    about formatting and positioning text and graphics.

  * [Recommended]
      Use logical styles rather than physical markups.  Do no
    misuse logical elements.
    Logical: DFN, EM, CITE, CODE, KBD, SAMP, STRONG, VAR, H1,
    H2, etc.
    Physical: size=14, B, I.
    This makes it easier for 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. The
    other advantage of logical elements is that they help
    enforce consistency in your documents.  It also leaves open
    the possibility for more sophisticated uses of the semantic
    encodings in the future.  For example, the Lycos indexing
    system can take advantage of semantic encoding to create
    abstracts of documents. Alternatively, browsers can navigate
    through a document by  logical styles, such as headers. Only
    use logical elements for what they represent.  For example,
    avoid using <cite> to undent a paragraph.

  * [Recommended]
      Avoid using the BLINK and MARQUEE elements. [Interim]
    Use another method to draw attention to text such as text
    size or color.

  * [Recommended]
      Properly nest headings. (Use style sheets for formatting
    [New] ).

Testing tips
  * 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.


Lists and Outlining

  * [Recommended]
      Correctly encode list structure and list items with proper
    HTML elements (UL, OL, LI). (Use style sheets to adjust item
    spacing [New]).

Tips and tricks:
  * Using a numbered (ordered) list makes it easier for people
    accessing the page auditorally to keep track of where they
    are within a list.


Tables

  * [Required]
      Explicitly associate table cells with row and column
    labels. [New]
    Future browsers and assistive technologies will be able to
    automatically translate tables into linear fashions if
    tables are tagged appropriately.  Refer to the first two
    tables examples given in the appendix.

  * [Required]
      Avoid using tables or <PRE> elements to arrange text
    documents in columns or otherwise layout a page. (Use style
    sheets to position graphics and text [New]).

  * [Recommended]
      Provide abbreviations for lengthy row or column labels.
    [New]
    Abbreviations 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.
    Refer to the examples given in the appendix.

  * [Recommended]
      Provide summaries of tables. [New]
    Summaries of table structure and purpose are especially
    useful for non-visual users.  Refer to the examples given in
    the appendix.

  * [Recommended]
      For more complex tables, group information into
    categories.  [New]
    Future browsers will allow users to select data from a table
    by asking for categories.  For example, a table contains
    information about several trips a person has recently made.
    One of these trips is to San Jose.  Information on expenses
    for meals, hotels and transportation are recorded (each in
    their own column).  There are several locations (San Jose,
    Seattle, Madison).  The expenses can be grouped into an
    "Expenses" category and all of the locations into a
    "Location" category.  The following question could then be
    asked, "What were all of my expenses in San Jose?" This
    means "What are all the data cells in the "Expenses=Meals,
    Hotels, Transport" and "Location=San Jose" categories?
    Refer to table example #3 in the appendix.

  * [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.

  * TBD
      For tables of text and numbers, provide an alternative
    page which presents the table information in a linear
    fashion. [Interim]
    There are several ways to link to alternative pages which
    are described in more detail in Methods for linking to
    alternative pages. This has not been rated because we
    couldn't decide if this was required or recommended.

  * [Recommended]
      Provide a phone or fax number or e-mail address if tables
    can not be made accessible.

Testing tips
  * 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.


Links - Hypertext and Media-Independent Links

  * [Recommended]
      Create link phrases that make sense when read out of
    context (but they 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, using "click here" as the text
    phrase for several links requires a user viewing the page
    with a screen reader to scout out each link to determine the
    context before selecting one. However, replacing "click
    here" with something more descriptive solves this problem.
    For example, "download this document in ASCII text," "view
    the full version in HTML," or "to view the text version,
    click here."

  * [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]

  * Methods for linking to alternative pages:
    * 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.  [Interim]
    * Provide the appropriate information in the header of the
      page so that the browser loads it automatically.  [New]
      If the user has set their default media type to "speech"
      this will load the alternative page automatically.  For
      example:

     <HEAD><LINK title="Text-only version" rel="alternate"
     href="text_only.html" media="speech"></HEAD>


Frames - Multi-view presentation of documents

  * [Required]
      Provide a <NOFRAME> option for each <FRAMESET>.
    When using the <NOFRAME> option it is easiest to include all
    essential information on the bottom of the main frame.
    Refer to the example in the master document.

  * [Recommended]
      Title each frame.[New]
    People accesing 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>


User-Input Forms

  * [Required]
      Do not use image maps to create graphical "submit" buttons.

  * [Required]
      Explicitly associate labels with their controls. [New]
    For example:

     <FORM action="http://somesite.com/adduser"
     method="post"
     <FIELDSET>
     <LEGEND align="top">Personal information</LEGEND>
     <LABEL for="firstname">First name: </LABEL>
     <INPUT type="text" id="firstname" tabindex="1">
     <LABEL for="lastname">Last name: </LABEL>
     <INPUT type="text" id="lastname" tabindex="2">
     ...more personal information...
     </FIELDSET>
     <FIELDSET>
     <LEGEND align="top">Medical History</LEGEND>
     ...medical history information...
     </FIELDSET>
     </FORM>

  * [Required]
      Provide alternative text for images used as "submit"
    buttons.
    For example, <INPUT type="image" name="submit"
    src="button.gif" alt="Submit">

  * [Recommended]
      Specify a logical tab order with "tabindex".[New]
    For example, (taken from the HTML 4.0 draft)

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

  * [Recommended]
      Group related controls with the <FIELDSET> element.[New]
    see the example for #2 - "Explicitly associate labels with
    their control."

  * [Recommended]
      Label a group of controls with the <LEGEND> element. [New]
    see the example for #2 - "Explicitly associate labels with
    their control."

  * [Recommended]
      Include default, place-holding characters in edit boxes
    and text areas. [Interim]

  * [Recommended]
      Include a phone number, e-mail address, postal address or
    fax number for submitting information.

  * [Recommended]
      Create keyboard shortcuts for form elements. [New]
    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>


Tips and tricks to further enhance the usability of pages

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

  * Use the "title" attribute on horizontal rules <hr title="new
    section">

  * Use the "title" attribute for acronyms and abbreviations
    <abbr>title="World wide web">WWW</abbr>

  * Use the "title" attribute for very short sounds <a
    href="mittens.wav" title="meow"></a>

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

  * Provide keyboard shortcuts for links.
    The "accesskey " attribute of <LABEL>, <A>, <CAPTION> and
    <LEGEND> 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>

  * Front-load link phrases in lists.


Good Web Site Design Practices

  * Page layout is consistent but pages or areas do not look
    identical.

  * A clear, consistent navigation structure is used.

  * Navigation bars provide easy access to the navigation
    structure.

  * Instructions are provided to describe the general layout of
    the site, the access features used, and how to use them.

  * A site map is available.

  * Different types of searches are available for different
    skill levels and preferences.

  * Nothing within the site prevents keyboard operation.

  * Elements outside of the HTML 4.0 specification (such as
    <BLINK> and <MARQUEE>) are not used

  * Use a design tool that supports access features (and does
    not remove access when you close, or reopen your page using
    the tool)

  * Test the site with AT LEAST:
    * a text only browser (such as Lynx)
    * a self-voicing browser (such as PWWebspeak)
    * Multiple graphic browsers, with:
      * sounds and graphics loaded,
      * graphics not loaded,
      * sounds not loaded,
      * no mouse


Appendix

Table examples

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

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

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

----------
ADVANCED DRAFT COPY

Page Author, User Agent and Assistive Technology Guidelines and
Issues - Version 8

Unified Web Site Accessibility Guidelines

December 1, 1997

Compiled by:
Gregg C. Vanderheiden Ph.D., Wendy A. Chisholm, M.S.,
Trace R and D Center, University of Wisconsin - Madison
For the Web Accessibility Initiative Guidelines Working Group

(This is a final Trace Center Guidelines Document.
It is compiled in preparation for transfer of the Guidelines to
the Web Accessibility Initiative of the W3C.
This guideline reflects recent work of the WAI as well as
previous contributions of many other guidelines developers
(listed in the appendix)).  Contributors include: 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 Ragget, 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

(If you have contributed and your name or organization is missing
from the above list, inform us via e-mail so that
we may correct our omission - and we apologize in advance.)

Prepared under funding from
the National Institute on Disability and Rehabilitation Research
(NIDRR),
Office of Special Education and Rehabilitation Services (OSERS),
US Department of Education
The US Postal Service's WINGS project and
the NCSA-PACI Universal Design / Disability Access Project.

(This is a living document. Comments and suggestions are
solicited.)


Table of Contents

  * About version 8 of the Unified Web Site Accessibility
    Guidelines
    * Introduction
    * Purpose of Version 8
    * Format of Version 8
    * Simplifying the Guidelines
    * Input Requested

  * Introduction to web site accessibility
  * [Place holder for "A brief SGML tutorial"]
  * Definitions and Conventions
    * Definitions
    * Types and encoding of recommendations

  * [Place holder for "HTML and URLs"]
  * [Place holder for "HTML Document Character Set - Character
    sets, character encodings, and entities"]
  * [Place holder for "Basic HTML data types - Character data,
    colors, and lengths"]
  * The global structure of an HTML document - The HEAD and BODY
    of a document
    * Page Titles
    * Metadata

  * Language information and text direction - International
    considerations for text
  * Text - Paragraphs, Lines, and Phrases
    * Text formatting
    * Acronyms
    * Punctuation, symbols and ASCII art
    * Text that changes or moves

  * Lists and Outlining - Unordered, Ordered, and Definition
    Lists
    * Helping users navigate lists effectively

  * Tables
    * Comprehension and navigation of table elements

  * Links - Hypertext and Media-Independent Links
    * Links read out of context
    * Identifying links within a sentence
    * Several links read as one
    * Methods for linking to alternate pages
    * Use of graphics decreases cognitive load and increases
      target area.
    * Page abstracts
    * Keyboard shortcuts for links

  * Objects, Images, Audio, and Applets
    * Introduction to the issues
    * General recommendations
    * Images and image maps
    * Applets
    * Audio and video

  * Style Sheets - Controlling the presentation of an HTML
    document
    * Style sheets solve several issues, but only if users can
      override

  * Alignment, font styles, and horizontal rules
    * Providing additional cues with horizontal rules

  * Frames - Multi-view presentation of documents
    * Misinterpretation by screen readers and small screen users

  * Forms - User-input Forms: Text Fields, Buttons, Menus, and
    more
    * Navigation and manipulation
    * Graphical buttons

  * Scripts - Animated Documents and Smart Forms
    * Introduction to the issues
      * Action occurring away from user focus
      * Actions executed during load of page
      * Automatic update of page ("push")
      * Summary of issues

  * [Place holder for "SGML reference information for HTML -
    Formal definition of HTML and validation"]
  * [Place holder for "SGML Declaration"]
  * [Place holder for "Document Type Definition"]
  * [Place holder for "Transitional Document Type Definition"]
  * [Place holder for "Frameset Document Type Definition"]
  * [Place holder for "Named character entities"]
  * Structure and Navigation of web sites
  * Appendices
    * Design Notes
      * Alt-text
      * Alternate pages

  * References


1. About Version 8 of the
Unified Web Site Accessibility Guidelines

1.1 Introduction

     The 8 series of website accessibility guidelines is
     the final set of unified guidelines prepared by the
     Trace Center. The Web Access Initiative (WAI) of the
     World-Wide-Web Consortium (W3C) has been launched, and
     the development of HTML guidelines is being
     transferred to that body. The Trace Center will be
     continuing to work with and as a part of the WAI. As a
     result, the Trace Center will no longer be developing
     or maintaining this Unified Website Accessibility
     Guideline series. Readers are referred to the W3C site
     (http://www.w3.org/wai) for the latest version of the
     guidelines.

1.2 Purpose of Version 8

     The primary purpose for compiling Version 8 is to
     bring together all of the information, notes, and
     ideas that the Trace Center has been able to locate
     (see appendix for listing of guidelines we were able
     to locate). This version also takes into account
     decisions and directions that were taken at the August
     1997 WAI working group meeting, as well as recent
     discussions by the working groups on-line (although at
     the present time, some of those discussions have not
     reached conclusion).

1.3 Format of Version 8

     Version 8 has been completely restructured from
     previous versions. Part of this was to reflect
     decisions or directions in which the WAI decided that
     it would like to take the guidelines at the August
     meeting. The greatest restructuring, however, has been
     done so that these web guidelines would directly
     follow the structure and numbering of topics in the
     new HTML 4.0 specification. In fact, in order to
     maintain the numbering, there are several sections in
     this document that have almost nothing in them, or are
     just place holders to keep the numbering aligned
     between these guidelines and the HTML 4.0
     specification.

     This document is actually one of a series of documents
     that make up the Unified Website Design Guidelines 8.
     The full set of guidelines include:

            * Web Access: Why Is It Important? (in 2
              pages or less)
              A brief introduction to the issues
              around web access for executives
              responsible for websites
            * Understanding Disabilities and Web
              Access Issues
              A discussion of the different types of
              disabilities and their effect on access
              to the web
            * A series of Check Lists
              * Checklist for web authors - about two
                printed pages
              * Checklist for user agent (browser)
                developers
              * Checklist for web server developers
              * Checklist for web tool developers

            * A series of Guidelines
              * Guidelines for web authors - about six
                printed pages
              * Guidelines for user agent (browser)
                developers
              * Guidelines for web server developers
              * Guidelines for web tool developers

            * The Unified Website Access Guidelines
              Master Document
              Presentation of web access issues along
              with solution strategies for web
              authors, browser developers, server
              developers, and tool developers, all in
              an integrated document so that the
              issues and the interactions between the
              authors, browsers, and tools may most
              easily be seen.
            * Web Access Resource Site
              A website containing extended
              discussions, case studies,
              demonstrations, tools, references to
              other guidelines and efforts related to
              web access, etc.

1.4 Simplifying the Guidelines

     In putting together these guidelines, we have tried to
     keep in mind that the simpler the guidelines were, the
     easier they would be to understand and follow.
     Unfortunately, HTML, formatting, and the Web are
     becoming increasingly complex. Also, browsers are
     introducing new elements and options. These present
     both opportunities and complications. In addition, we
     need to take into account the fact that although some
     of the pages out there on the Web will be using the
     new features, there is still a legacy of pages using
     old techniques, only a small portion of which will
     probably ever be updated and reformatted. We are
     therefore trying to follow the advice of Albert
     Einstein, who said "Everything should be made as
     simple as possible, but no simpler." This first draft
     is an attempt to reach our objective. In it, we have
     tried to incorporate all of the new information and
     strategies, and to present them in as straightforward
     and useful a fashion as possible. Our goals in this
     first version are therefore: correct, complete,
     simplify, in that order. In fact, since this set of
     guidelines is being used as a central reference point
     by so many, we need to always maintain that order.
     However, we recognize the need for simplicity, and
     that will be a primary focus, particularly of the
     short form and checklist versions.

C2S2 Approach

     The Trace Center has also launched what they call a
     "C2S2 Project." This stands for the "Comprehensive
     Cross-Segment Strategy Project." In a nutshell, this
     project seeks to identify and define a way that
     different industry segments (authors, user agent
     [browser] developers, and assistive technology
     developers [e.g., screen reader manufacturers]) can
     coordinate their efforts. The goals of this
     cooredination are:
       * To minimize the effort needed by page authors to
         make their sites accessible.
       * To maximize the flexibility and creativity of page
         authors to create web-based environments.

     For example, currently, page authors have to follow
     several rules that are not necessary if some basic
     capabilities or options were built into browsers and
     screen readers. C2S2 seeks to work with all of the
     segments to identify a cooperative strategy that
     divides up the access issue and identifies ways that
     the different industry segments could cooperate to
     minimize the number of guidelines and amount of effort
     needed. These guidelines reflect and help support the
     C2S2 approach by identifying, under each issue, the
     strategies and approaches that could be taken by all
     of the industry segments to help address the access
     issue. More information on the C2S2 project is
     available at http://trace.wisc.edu/docs/c2s2/c2s2.htm.

1.5 Input Requested

     As always, any and all comments on this draft are
     solicited. This 8 series, however, will formally
     freeze on November 10. At that point, the guidelines
     in their current form will be formally transferred to
     the WAI, which will then, per previous decision, use
     them as a basis for developing the formal WAI
     guidelines. Once the W3C/WAI guidelines are released,
     these guidelines will be archived and website authors
     will be directed to the W3C/WAI guidelines.


2. Introduction to Web Site Accessibility


2.1 Profiles of users with disabilities

Sensory disabilities - vision, audition

     Low vision - There are many types of low vision,
     including poor acuity, tunnel vision, clouded vision,
     floaters in the eye, peripheral vision, etc. Some
     people with low vision need to enlarge the text fonts
     and images, and may use use a dual (i.e., partial) or
     full screen magnifier.

     Note, low vision users may still encounter difficulty
     deciphering information on the computer screen even
     when magnified due to:
       * magnifying small fonts or images may cause
         pixelation and/or distortion ;
       * magnified areas tend to loose contextual
         information (tunnel vision effect doesn't allow
         user to "see" what information or choices are
         around the magnified area).

     Blindness - People are legally blind when they have
     less than 20/200 vision in the better eye after
     correction, or less than a 20 degree field of view in
     the better eye after correction. Individuals who are
     blind rely primarily on screen readers to read the
     text on the screen. For graphic elements, they rely on
     the presence of a text description of the image (and
     any text that is included as an image in the
     document).

     Hard of hearing - A person whose hearing is less
     severely impaired than deafness is said to be hard of
     hearing.

     Deafness - A person is considered deaf when sound must
     reach at least 90 decibels to be heard at all and even
     amplified speech cannot be understood. Normal
     conversation is approximately 40 to 60 decibels.

Physical disabilities - paralysis, fine-motor skills

     There is a tremendous variety of physical
     disabilities. In addition to the usual range from
     minor to severe involvement, there are also many
     different types of physical disabilities. In order to
     better understand its breadth, it is useful to break
     this category into two major areas: neuromuscular and
     skeletal. Neuromuscular impairments include any
     impairments that relate to the nervous system
     (including the brain) or the muscles. For example,
     most speech impairments fall into this area. Skeletal
     impairments relate to the bones, joints and missing
     limbs.

     Although there are many specific types of neurological
     impairments, their effects can be characterized as
     variations or combination of:
       * Paralysis - This lack of any muscular control and
         often sensation in part of the body. This is
         usually caused by a break in the nerves leading to
         the muscle, often in the spinal cord.
       * P aresis - Weakness or inability to produce small,
         controlled or forceful movements. This can be
         caused by problems with the signals sent to the
         muscles via the nerves, problems with the muscles
         themselves, or problems due to pain when movements
         are made (as in the case of severe arthritis).
       * Interference with Control - This interference can
         take different forms. The term spasticity is used
         if the muscles are tense and contracted and
         voluntary movements is very difficult. Ataxia
         refers to problems in motor programming and
         coordination. Athetosis and Chorea refer to
         constant or uncontrolled motion (i.e. extra,
         involuntary movements).

Cognitive disabilities - learning, attention deficit

     These disabilities result from some type of damage to
     the human brain. Therefore it is not surprising that
     there is a great complexity of impairments in this
     category. Cognitive disabilities can be divided into
     the following seven categories:
       * Impairments of Intelligence and Thinking
         * Mental Retardation
         * Dementia

       * Impairments of Memory
         * Amnesia
         * Memory illusions
         * Forgetfulness

       * Other Intellectual Impairments
       * Aphasia
       * (Specific) Learning Disabilities
         * Spoken language
         * Written language
         * Arithmetic
         * Reasoning

       * Psychological impairments
       * Drug and Alcohol Dependence


3. [Place holder for "A brief SGML tutorial"]


4. Definitions and Conventions

4.1 Definitions

Assistive Technologies

     Assistive technologies are products used to help
     people accomplish tasks that they can not accomplish
     otherwise. For example, eyeglasses assist those of us
     who can not see clearly. When dealing with computers
     and the world wide web, assistive technologies usually
     refer to software adaptations, specially designed
     hardware devices, and/or standard devices used in
     alternative ways which provide user access.

Screen reader

     A software program that reads the contents of the
     screen aloud to a user. Used primarily by individuals
     who are blind, screen readers can only read text that
     is printed, not painted, to the screen.

Screen magnifier

     A software program that magnifies a portion of the
     screen, so that it can be more easily viewed. Used
     primarily by individuals with low vision.

ShowSounds and SoundSentry

     Individuals who are deaf or hard-of-hearing can set
     the "ShowSounds" and "SoundSentry" flags on some
     operating systems such as Windows95/NT. If the
     SoundSentry flag is set, whenever the computer makes a
     sound, a user chosen visual indication is provided on
     the screen. Any programs which have significant aural
     or spoken content should check to see if the
     ShowSounds flag is turned on. If it is, these programs
     should also provide all significant aural content in a
     visual format (e.g., closed captions).

Scanning Software

     Software that highlights (and/or announces) selection
     choices (e.g. menu items, groups of possible phrases,
     etc.) one at a time. A user selects a desired item by
     hitting a switch when the desired item is
     highlighted/announced. Used primarily by individuals
     with severe physical or cognitive disabilities.

Alternate Keyboards

     Hardware/software devices that provide an alternate
     way of creating keystrokes that appear to be coming
     from the standard keyboard. On-screen keyboards,
     speech input, eyegaze keyboards, and sip-and-puff
     (Morse code) keyboards are some examples. Used
     primarily by individuals with disabilities that
     prevent them from using the standard keyboard (and
     usually from using the mouse as well). Programs that
     can be operated entirely from the standard keyboard
     (and don't require the mouse) can be used by
     individuals with alternate keyboards.

Braille and Dynamic Braille

     Braille is a technique involving six dots which are
     raised in different patterns to represent letters and
     numbers so that they can be read by people who are
     blind using their fingertips. Grade II braille
     includes additional codes that represent common letter
     groupings (e.g., "th," "ble") to make braille more
     compact. An 8-dot version of braille has been
     developed to allow all ASCII characters to be
     represented. Dynamic braille involves the use of a
     display where dots can be raised and lowered
     dynamically to allow any braille words to be
     displayed. Only letters and numbers can be represented
     in braille, although some braille printers have a
     utility that allows simple graphics to be drawn on a
     sheet using the raised dots at a resolution of
     approximately 11 dots per inch.

     The word "Accessible" in Braille.

The word "Accessible" in Grade II Braille.


4.2 Types and encoding of recommendations

Rating System

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

     [Recommended] - Makes page easier to understand and
     use.

Classification System

     [Interim] - Strategies needed to make pages accessible
     for today's browsers and assistive technologies

     [New] - Strategies that will take advantage of new
     features being incorporated into supported tomorrow's
     browsers and assistive technologies (which incorporate
     Web Access Initiative recommendations).

     If a recommendation has several possible strategies,
     the strategies are classified, if not the
     recommendation itself is classified.  Those
     recommendations and strategies that have no
     classification work for both old and new browsers.

Recommendations for different groups

     There are several pieces of the puzzle that need to be
     put together for a single page to be accessible. This
     document focuses mainly on what page authors should be
     doing to ensure that browsers render the page as
     maximally accessible as they can. We do offer
     suggestions for browser and assistive technology
     designers, and even a few hints for users. The
     following headings are used throughout the document:
       * Recommendations for page authors - issues to be
         handled in source documents
       * Recommendations for user agent (browser) designers
         - issues to be handled by browsers
       * Recommendations for Assistive Technology designers
         - issues to be handled by screen readers, screen
         magnifiers, scanning software, etc.
       * Suggestions for Users - configuring the user agent
         and assistive technology for maximum benefit.


5. [Place holder for "HTML and URLs"]

6. [Place holder for "HTML Document Character Set"]

7. [Place holder for "Basic HTML data types"]


8. The global structure of an HTML document

The HEAD and BODY of a document


8.1 Page Titles

     Issue:  Meaningful titles should be associated with
     each page not only because they are required in HTML
     4.0, but users will more easily identify bookmarked
     pages. Most browsers will use the address of a web
     page if no title is provided.

Recommendations for page authors

     Design Tip:  Use the TITLE element in the HEAD of each
     document.
     For example, <HTML><HEAD>...<TITLE>Version 8 of the
     Unified Web Accessibility
     Guidelines</TITLE>...</HEAD>...


8.2 Metadata

     There are many recent developments on this front that
     are still being discussed. Hopefully, in the near
     future, authors will be able to associate a variety of
     metadata with their pages. Stay tuned.


9. Language information and text direction

International considerations for text



10. Text

Paragraphs, Lines, Phrases,
Punctuation and Symbols

       * 10.1 text formatting
       * 10.2 Acronyms
       * 10.3 Punctuation, symbols and ASCII art
       * 10.4 Text that changes or moves


10.1 Text formatting

     Issues: There are four issues with the presentation of
     text:
       * Authors often use color, font style (e.g. bold or
         italic) or font changes to highlight certain words
         or to make a page easier to read visually (e.g.
         headings are italicized, outdented, a larger font
         and bold).  While this often makes the page easier
         to read visually, it is either lost in the aural
         presentation or makes the aural presentation
         confusing.  In some instances, important
         information is being conveyed through the
         typographics used and is lost to the auditory
         user.  The following is an expansion of the issues:
         * Color, font or font size - These typographic
           attributes often highlight a section of text.
           For example,  to signify a heading, or to
           emphasize an important statement.  Since most
           screen readers read all text in the same manner,
           no matter what visual attributes they possess,
           the meta information given in the example is
           lost.  Headings not only make it easier to skim
           through a page, they signify that a major change
           in context has just occurred and give the new
           context a "handle."   The loss of this
           information can make a document harder to
           understand.
         * Indentation - Indentation is usually used to
           order or to group items. Most screen readers do
           not indicate how much space precedes or follows
           text.  The issues are discussed in greater
           detail in the section on Lists.
         * Drop-caps, subscripts and superscripts.  Current
           screen readers might interpret words or letters
           as appearing on a separate line.

       * Users need to  adjust text size for easier viewing
         if they have low vision. Changing the text size
         often makes the page unreadable due to changes in
         layout.
       * Although users can override the color settings of
         HTML pages to alleviate poorly contrasting colors,
          formats such as Portable Document Format (PDF)
         prevent this. Also, some users may not yet be
         aware that they have this ability.
       * Screen reading software cannot make sense of
         bit-mapped text since it is perceived as graphical
         information. One of the most common examples of
         bitmap text is the counter that records the number
         of accesses to a certain page. For example, a
         text-only browser or screen reader might say the
         word "image" when it encounters a graphic.
         Reading a page with a graphical counter would
         sound like, "You are visitor number (image) to
         visit this site" or "The number of visits to our
         site this month is (image)."

     Elements affected:   EM, STRONG, DFN, CODE, SAMP, KBD,
     VAR, CITE, BLOCKQUOTE, Q, IMG, FONT, SUB and SUP

Recommendations for page authors

[Required]
  Use style sheets: [New]
    * to create drop caps, subscripts and superscripts
    * to highlight sections of a document with font size,
      formatting or color
    * rather than converting text to images or alternative text
      file formats (such as PDF)

  * [Recommended]
      Use logical styles rather than physical markups.  Do no
    misuse logical elements.
    Logical: DFN, EM, CITE, CODE, KBD, SAMP, STRONG, VAR, H1,
    H2, etc.
    Physical: size=14, B, I.
    This makes it easier for 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. The
    other advantage of logical elements is that they help
    enforce consistency in your documents.  It also leaves open
    the possibility for more sophisticated uses of the semantic
    encodings in the future.  For example, the Lycos indexing
    system can take advantage of semantic encoding to create
    abstracts of documents. Alternatively, browsers can navigate
    through a document by  logical styles, such as headers. Only
    use logical elements for what they represent.  For example,
    avoid using <cite> to undent a paragraph.
  * [Recommended]
      Avoid using the BLINK and MARQUEE elements. [Interim]
    Use another method to draw attention to text such as text
    size or color.

  * [Recommended]
      Properly nest headings. (Use style sheets for formatting
    [New] ).
    Users with dyslexia may have problems reading long pages and
    will be helped if the design facilitates scanability by
    proper use of headings. This also benefits us all, as we
    scan through pages via the headings. Tagging these correctly
    means that user agents can provide navigation through the
    structure.

Testing tips
  * 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.

Recommendations for user agent (browser) designers

       * Allow user-selected style sheets to override the
         page author's settings.
       * Support navigation between different size
         "chunks." For example, allow the user to jump
         between links, or level 2 headings, or by
         sentence, or whatever they choose.

Recommendations for assistive technology designers

     If user agents do not support the previous
     recommendation, then that functionality should be
     implemented here (although this requires parsing of
     HTML).

Suggestions for users

  * Make use of existing (or create your own) Aural Cascading
    Style Sheet (ACSS) to interpret the page constructs as you
    desire.
  * To translate PDF files, download Adobe's plug-in for windows
    or retrieve documents through their proxy. For more
    information, go to the Adobe site at
    http://access.adobe.com/.


10.2 Acronyms

     Issue: Acronyms may be unfamiliar to readers or
     interpretted incorrectly based on previous experience.
      For example,  "CID" can stand for "Central Institute
     for the Deaf, " "Charge Injection Device," "Computer
     Integrated Design," or
     "Configuration/Installation/Distribution"  depending
     on your context. For disability access, screen readers
     may not recognize the phrase as an acronym and might
     make a best guess at pronouncing it.  Not only can
     this sound ridiculous, it can be confusing.

     Element affected:  ABBR

Recommendations for page authors

     Design Tip:  Use the "title" attribute for acronyms
     and abbreviations <abbr>title="World wide
     web">WWW</abbr>

Recommendations for user agent (browser) designers

     Make title information available or present it inline
     if requested by the user.


10.3 Punctuation, symbols and ASCII art

     Issue:  Screen reading software will often either
     ignore or read each name for punctuation used to make
     an emoticon or ASCII art.  For example, the smiley
     emoticon :-) would either be ignored or read as "colon
     dash close parentheses."

     Text symbols affected: all punctuation and letters
     that are used to make emoticons, symbols or ASCII art

Recommendations for page authors

     Design Tip:  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..


10.4 Text that changes or moves

     Issue:  Text that changes or moves 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").  For example, a
     user with attention deficit disorder might find it
     hard to focus on the rest of a page while blinking or
     scrolling text is present. Another example, marquee
     text, is often read by most current screen readers
     (which do not interpret the HTML) one letter at a time
     as it appears on screen. Therefore, the visible words
     and characters of the message will be repeated each
     time a new letter appears. For example, the message
     "Have a nice day,"  scrolling left to right:

                                                          
          Message that is          What is read to the    
          visible on screen        user                   
                                                          
          H                        "H"                    
                                                          
          Ha                       "Hah"                  
                                                          
          Hav                      "Have"                 
                                                          
          e a nice day             "E A nice day"         
                                                          
     Elements affected: BLINK, MARQUEE, as well as
     programming or scripting languages, such as Java and
     JavaScript.

Recommendations for page authors

  * [Required]
      Provide a mechanism for the user to freeze any moving or
    blinking 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.
  * [Recommended]
      Avoid using the BLINK and MARQUEE elements. [Interim]
    Use another method to draw attention to text such as text
    size or color.

Recommendations for user agent (browser) designers

     Allow users to view BLINK and MARQUEE phrases as
     static text.
     This goes for all animations and interactions. See the
     sections on Applets and Scripts for more information.

     Side note: MARQUEE is a MSIE3.0 element, while BLINK
     was introduced in Netscape 1.1.  Therefore, neither
     are considered standard HTML.


11. Lists and Outlining

Unordered, Ordered, and Definition Lists


11.1 Helping users navigate lists effectively

     Issue:  Non-visual users often "get lost" in lists,
     especially those with several layers of embedding and
     those which lack discernible cues to indicate the
     specific level of indentation for each item. In
     addition, it is often difficult for non-visual users
     to know where the list itself begins and ends and
     where each  list item starts. Further, if a list entry
     wraps to the next line, it may appear to be two
     separate items in the list.

     For example, imagine stripping the indentation and
     bullets from a list of items I keep in my desk:
       * writing utensils.
         * pens
           * highlighters
             * red
             * green
             * blue

           * ball-point
             * green
             * purple
             * blue

         * pencils
           * #2 lead
           * soft lead

       * erasers

     It might be read like this by a screen reader:

          writing utensils.
          pens
          highlighters
          red
          green
          blue
          ball-point
          green
          purple
          blue
          pencils
          #2 lead
          soft lead
          erasers

     Elements affected: OL, UL, LI, DL, DD, DT, BLOCKQUOTE

Recommendations for Page Authors

  * [Recommended]
      Correctly encode list structure and list items with proper
    HTML elements (UL, OL, LI). (Use style sheets to adjust item
    spacing [New]).
  * This is an ongoing topic of discussion, stay tuned for
    developments.

Tips and tricks:
  * Using a numbered (ordered) list makes it easier for people
    accessing the page auditorally to keep track of where they
    are within a list.

Recommendations for user agent (browser) designers

  * Introduce each list by indicating how many items it contains.
    For example, "There are 6 subtopics." or "7 Objectives of
    this study are:". This information is helpful in orienting
    users as to how long a list is that they are about to read.
    Numbering lists also addresses cognitive disabilities. The
    organization in a page with numbered lists and an indicator
    of the upcoming page structure helps someone's understanding
    of a Web page.
  * Allow the user to configure how nested lists should be
    enumerated and presented.
    This includes allowing the user to choose to view all text
    in a left-justified format if they so desire or to associate
    an aural cue with different levels (via alternate aural
    cascading style sheets).


12. Tables


12.1 Comprehension and navigation of table elements

     Issue 1:  Newspaper columns. Tables are often used to
     layout pages of text in newspaper columns.  Most
     current screen readers (which do not interpret the
     HTML) read all the way across the page reading
     sentences on the same row from different columns as
     one sentence.

          For example:

                                                          
          There is a 30%          Classes at the          
          chance of rain          University of           
                                  Wisconsin               
                                                          
          showers this            will resume on          
          morning, but the        September 3rd.          
                                                          
          weekend looks like                              
          it will be sunny.                               
                                                          
          This might be read by a screen reader as:
          There is a 30% chance of rain Classes at the
          University of Wisconsin
          showers this morning, but the will resume on
          September 3rd.
          weekend looks like it will be sunny.

     Issue 2:  Spreadsheets and calendars. Tables are often
     used to layout text and numbers.  The screen reader
     may append all of the numbers from different columns
     in the same row into one large number if spaces and
     punctuation are not provided.

     Issue 3:  Alt-text that wraps. If the alt-text of
     graphics laid out in a table wrap, then the "column
     effect" described above will occur, making the table
     difficult or impossible to decipher. For example,
     tables are often used to layout graphics to create
     navigation bars.  In this instance the alt-text for an
     image might be wrapped to fit the width of the column
     that it is placed in.  The following table represents
     what a reader might see if images were not viewed on
     an example opening page:

                                                                       
  Welcome                    Sponsored     Help            Search      
  to our                     by                                        
  site                       XYZ company                               
                                                                       
  Products,   Virtual        Games and     Employment      Background  
              tour of our    educational   opportunities               
  projects    headquarters                                             
  and                        offerings                                 
  research                                                             
  news                                                                 
                                                                       
          Since each of these cells represents a
          graphic, and each graphic is a link to
          another page, a user tabbing through the
          page might hear:
          "Welcome to our" [tab] "Sponsored by" [tab]
          "site" [tab] "XYZ company" [tab] "Help"
          [tab] "Search" [tab] "Products" [tab] "Games
          and" [tab] "project and" etc.

     Issue 4:  In all of these instances, it is very
     difficult to comprehend the semantics of the table
     since navigation through a table with most current
     screen readers (which do not interpret the HTML) is so
     limited.  The user is forced to navigate by sentence,
     without the options to navigate by row, column or cell.

     Elements affected:   TABLE, CAPTION, THEAD, TFOOT,
     COLGROUP, TBODY, TH, TD, TR, and their attributes

Recommendations for page authors

  * [Required]
      Explicitly associate table cells with row and column
    labels. [New]
    Future browsers and assistive technologies will be able to
    automatically translate tables into linear fashions if
    tables are tagged appropriately.
    * "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

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

  * [Required]
      Avoid using tables or <PRE> elements to arrange text
    documents in columns or otherwise layout a page. (Use style
    sheets to position graphics and text [New]).
  * [Recommended]
      Provide abbreviations for lengthy row or column labels.
    [New]
    Abbreviations 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.
    Refer to the examples given in the appendix.

  * [Recommended]
      Provide summaries of tables. [New]
    Summaries of table structure and purpose are especially
    useful for non-visual users.  Refer to the examples given in
    the appendix.

  * [Recommended]
      For more complex tables, group information into
    categories.  [New]
    Future browsers will allow users to select data from a table
    by asking for categories.  For example, a table contains
    information about several trips a person has recently made.
    One of these trips is to San Jose.  Information on expenses
    for meals, hotels and transportation are recorded (each in
    their own column).  There are several locations (San Jose,
    Seattle, Madison).  The expenses can be grouped into an
    "Expenses" category and all of the locations into a
    "Location" category.  The following question could then be
    asked, "What were all of my expenses in San Jose?" This
    means "What are all the data cells in the "Expenses=Meals,
    Hotels, Transport" and "Location=San Jose" categories?

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>

  * [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.

  * TBD
      For tables of text and numbers, provide an alternative
    page which presents the table information in a linear
    fashion. [Interim]
    There are several ways to link to alternate pages which are
    described in more detail in Methods for linking to alternate
    pages.

  * [Recommended]
      Provide a phone or fax number or e-mail address if tables
    can not be made accessible.

Testing tips
  * 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.

Recommendations for user agent (browser) designers

  * Make cell, row and column information available.
    Semantic information is provided through attributes
    available for each entry in the table, the row and column
    information as well as the cell's data contents. This will
    most likely emerge in the next HTML 4.0 specification as
    AXES, AXIS, and SCOPE attributes. As the draft solidifies we
    will provide more information about how to use the new
    attributes.
  * Provide methods to "unwrap" table information.
    How a table is unwrapped will be determined by which
    attributes are added to HTML 4.0. There has been
    considerable discussion about this in the WAI working groups
    and we will update this recommendation as soon as it is
    resolved.

Recommendations for assistive technology designers

  * Provide the ability to navigate by column, row and cell.
  * Provide orientation functions.
    To help the user determine which row or column they are in,
    and to establish how the current cell contents relate to the
    rest of the table, a "where am I" feature is needed.


13. Links

Hypertext and Media-Independent Links

  * 13.1 Links read out of context
  * 13.2 Identifying links within a sentence
  * 13.3 Several links read as one
  * 13.4 Methods for linking to alternate pages
  * 13.5 Use of graphics decreases cognitive load and increases
    target area.
  * 13.6 Page abstracts
  * 13.7 Keyboard shortcuts for links


13.1 Links read out of context

     Issue: People who use screen readers to access the
     information on the web will often use the tab key to
     step through the links on a page. Although this allows
     users to more quickly identify links, they will not
     hear the surrounding text and will lose the context of
     the link. Pages that use the same phrase for several
     different links (e.g. a series of "click here's") are
     impossible to navigate solely by reading the links.
     Microsoft Internet Explorer 4.0 can create an overview
     of a page by presenting a list of just the links on
     the page. This might become a popular method to scan
     pages by everyone.

     Element affected:  A

Recommendations for page authors

     [Recommended]
       Create link phrases that make sense when read out of
     context (but they 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, using "click
     here" as the text phrase for several links requires a
     user viewing the page with a screen reader to scout
     out each link to determine the context before
     selecting one. However, replacing "click here" with
     something more descriptive solves this problem. For
     example, "download this document in ASCII text," "view
     the full version in HTML," or "to view the text
     version, click here."

Recommendations for user agent (browser) designers

  * Provide a feature that displays either:
    * A list of links
    * A list of links which each link followed by its
      surrounding text.
      For example, click here; To find out more about how the
      west was won, click here.
    * OR A list of headers and links


13.2 Identifying links within a sentence

     Issue: It is difficult for users of screen readers to
     identify links included within a sentence since there
     are no aural differences of how links are read versus
     other words. Visual users are able to detect links by
     color coding and underlining.

Recommendations for user agent (browser) designers and/or
assistive technology designers

     Provide an option to insert a character(s) or a blank
     line before each link or associate an aural cue with
     links.
     Characters are one way of associating an aural cue
     with links, since it will be spoken by those using
     screen readers. However, this cue usually does not
     help determine where the link ends whereas a sustained
     background sound that is played during the reading of
     a link or a change in the pitch of the voice would.


13.3 Several links read as one

     Issue:  Currently, lists of links are sometimes read
     as one link by most current screen readers (which do
     not interpret the HTML). Sometimes this happens even
     when the links are on different lines. The user is
     unable to position the mouse cursor on any of the
     specific links, making the links inaccessible.

Recommendations for page authors

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

Recommendations for assistive technology designers

     Links should be spoken separately with pauses in
     between.


13.4 Methods for linking to alternate pages

     Issue :  Oftentimes an alternate version of a page is
     available as a link from the current page.  Alternate
     pages can be text-only versions of a page, the page
     translated to another language, or a more succinct
     presentation of the information.

     When creating text-only versions of pages, there are
     several issues to be aware of:
       * The text-only page might link back to a
         graphic-intensive page, which has an alternative
         link for a text-only page.  This hopping back and
         forth can dramatically increase the time required
         to navigate the site.  Especially if the link for
         the text-only version is buried in the page.
       * It is easy to see that creating text-only versions
         of every page on a site could double the number of
         pages that need to be maintained. Three methods
         for generating and maintaining text-only pages are
         described in the section Methods to create
         alternate pages found in Appendix A. Some of these
         methods generate text-only pages automatically.

Methods for page authors

  * Provide a visible link at the top of each page to allow a
    user to move back and forth between the graphic and
    alternate versions of the page, if they wish to do so.
    [Interim]
  * Provide the appropriate information in the header of the
    page so that the browser loads it automatically.  [New]
    If the user has set his or her default media type to
    "speech" this will load the alternate page automatically:
    <HEAD><LINK title="Text-only version" rel="alternate"
    href="text_only.html" media="speech"></HEAD>

Recommendations for user agent (browser) designers

     Allow users to select a default media type (screen,
     print, projection, braille, or speech).
     If a page is specifically created for their selected
     default media type, load the appropriate page
     automatically.


13.5 Use of graphics decreases cognitive load and increases
target area

     Issue: For web-surfers with some degree of motion
     impairment, selecting text links can be difficult
     because of the small target area and dexterity needed
     to select them with a mouse pointer. Therefore they,
     along with people with cognitive disabilities and
     people who cannot read well, often find that photos
     and graphics/icons make it easier to navigate and
     comprehend a site. While the use of graphics poses
     problems for users with visual disabilities, it may
     make it more obvious for someone else who has
     difficult reading and/or understanding the content. To
     learn more about how to make images accessible to
     people with visual disabilities, see the section
     Viewing and interacting with images and image maps.
     Keep in mind that the design of effective icons is not
     a trivial task due to the variety of possible
     interpretations by people based on personal
     differences.

Recommendations for page authors

  * Design Trick: Provide hyperlinks that use enlarged font
    sizes or graphical buttons to make the target area larger.
    However, make sure that you follow the guidelines for style
    sheets and alt-text so that you do not cause problems for
    people with visual disabilities.

Recommendations for user agent (browser) designers

  * Support "tabbing" between links.
  * Allow the user to select font color and size of text links.
  * Consider creating a bookmark function that allows a person
    to associate a picture with each bookmark.
    Selecting a favorite page then becomes a matter of locating
    the image they associate with it.


13.6 Page abstracts

     Issue: It seems that it would be beneficial if
     metadata information could be stored with a link or
     retrieved separate from the entire page to provide a
     better picture of where the user is headed. Some
     information that might be helpful is a description of
     where the page going to, size of the page, purpose of
     the link, author, etc. Or, the creation of a page
     "abstract" that could be retrieved and viewed before
     the whole page was loaded.

Recommendations

     There are no recommendations at this time. Further
     exploration is needed and solutions solicited.


13.7 Keyboard shortcuts for links

     Design Trick: Provide keyboard shortcuts for links.
     The "accesskey " attribute of <LABEL>, <A>, <CAPTION>
     and <LEGEND> 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>


14. Objects, Images, Audio, and Applets

Multimedia in HTML documents

  * 14.1 Introduction to the issues
  * 14.2 In general
  * 14.3 Viewing and interacting with static images and image
    maps
  * 14.4 Viewing and interacting with applets
  * 14.5 Audio and video


14.1 Introduction to the issues

     Multimedia provides the greatest number of barriers
     for the greatest number of people for the following
     reasons:
       * Some users are unable to see images, movies or
         other types of animations CLEARLY either because
         they are colorblind, they have low vision, or they
         do not have a high resolution display.
       * Some users are unable to view images, movies or
         other types of animations AT ALL either because
         their eyes are currently busy (they are driving),
         they do not have the proper software, have
         text-based software, have a slow data connection,
         are blind or very low vision, or they are
         accessing the information via phone interface.
       * Some users are unable to hear movie sound tracks,
         audio clips or other types of audio information
         because they work in a loud environment (and the
         computer noises are masked by the environmental
         noises), work in a quiet environment (and need to
         turn the speakers off so as not to disturb
         others), do not have the proper software, hardware
         or enough memory to run the software, have a slow
         data connection, or are deaf or hard of hearing.


14.2 General Recommendations

     The following recommendations apply to images, sounds
     and multimedia.

     Elements affected:  OBJECT, IMG, APPLET, A

Recommendations for page authors

  * Background patterns and color should contrast well with the
    lettering to maintain readability (background refers to both
    backgrounds of pages and backgrounds of images).
    * Avoid using similar hues together. For example, do not
      place blue-green lettering on a blue background. Dark
      shades of blue, violet, purple or black lettering on
      backgrounds of light shades of blue-green, green, yellow
      or orange are easiest to read. For more information on
      color contrast for people with low vision and color
      deficiencies contact The Lighthouse, Inc. for their
      pamphlet Color Contrast and Partial Sight [(800) 334-5497]
      which is also available on the web at
      http://www.lighthouse.org/1lh32a.html.
    * Design graphics with just 16 colors so that colors do not
      change across platforms, i.e. it might be unreadable on a
      different platform.

  * Make color coding redundant with other means of conveying
    information.
    For example, distinguish glossary words with the color red
    as well as with emphasis.
  * For troublesome pages, link to an alternative page
    Whenever you have trouble making a page directly accessible,
    provide a second version of the page which replaces any
    graphics, applets, movies or audio with text descriptions or
    transcripts and replaces buttons and other active areas with
    text links. There are several ways to do this which are
    described in more detail in Methods for linking to alternate
    pages (in Appendix B).

Recommendations for user agent (browser) designers

  * Allow users to designate whether they want to download and
    view multimedia and applets.
  * Display the alternate media associated with the element if
    the user selects not to view multimedia .
    This includes:

       * Alternate text for images.
       * Alternate text for each link of an image map
         (client side).
       * Alternate renderings for objects included with the
         OBJECT element. An HTML example is in the section
         on applets. Then an applet, either a movie, a
         still image or text description could be loaded
         based on the user's preferences.
       * Transcripts for movies.
       * Transcripts or descriptions of audio clips.

Suggestions for users

     If you have a slow modem connection (14400 kbps or
     less), are unable to see, or do not care to see
     multimedia or applets, your browser should provide a
     way to select whether or not you wish to download this
     information.  Lynx and other text-based browsers do
     not support graphics and you will not need to
     configure anything.


14.3 Images and image maps

     Elements affected:  OBJECT, IMG

Recommendations for page authors

  * [Required]
      Provide alternative text for all images and image maps.
    All images 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 solution
    strategies include:
    * 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">.
    * [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>

Several tips and tricks concerning alternative text are in the
appendix.

  * [Required]
      Provide a link to a longer description (i.e., via D-link,
    or longdesc, etc.) for graphics that present important
    information (especially charts, tables and diagrams).
    (Include internal text in image file formats that support
    it).
    Alternative text descriptions (recommendation #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.
         * [Interim] Provide a 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>
         * [New] Use the "longdesc" attribute of the <IMG>
           element or provide text within the body of the
           <OBJECT > element. For example, <IMG
           SRC="97sales.gif" alt="Sales for 1997"
           longdesc="sales.html">

     The description found on the page "97sales.html" might
     read something like: "This chart shows how many
     widgets we sold in each of our four regions, North,
     South, East and West. In the North we sold 2,000
     units. In the South 5,000 units. In the East 6,000
     units and in the West 8,000 units."

     WGBH pioneered the practice of placing a capital "D"
     text link next to pictures or graphics which link to a
     longer description of the graphic. Since the letter
     "D" is not a very descriptive phrase for a link, if
     you use this method you should include an explanation
     of what it represents and why. Another option is to
     use a more descriptive text link, such as "or a
     description of xxx."

  * [Required]
      Use client-side (instead of server-side) image maps.
    Client-side image maps are similar to server-side image maps
    except that the information for all of the "hot-spots"
    within the image are sent to the browser along with the
    image map picture. Descriptions provided with the URLs can
    be displayed rather than the graphic. If server-side image
    maps can not be avoided, see the 5th strategy of the next
    recommendation.
  * [Required]
      Provide a description for each link in an image map.
    Depending on how you've created your image map you have
    several possibilities:
    * Use the "alt" attribute of the <AREA> element (with the
      IMAGE, MAP and AREA elements)
      <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] Use the "alt" attribute of the <AREA> element (with
      the OBJECT, MAP and AREA elements)
      <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="reference.html"
      alt="Reference">
      <AREA coords="34,34,100,100" href="media.html" alt="Audio
      Visual lab">
      </MAP>
    * [New] Use the "title" attribute of the <A> element (with
      the OBJECT and SHAPES elements)
      <OBJECT data="welcome.gif" shapes>
      Areas in the library
      <A coord="0,0,30,30" href="reference.html"
      title="Reference">Reference</A>
      <A coords="34,34,100,100" href="media.html" title="Audio
      Visual lab">Audio Visual Lab</A>
      </OBJECT>
    * [New] Create a descriptive paragraph within the <OBJECT>
      element that includes the links (using the OBJECT and A
      elements)
      <OBJECT data="welcome.gif" shapes>
      There are several areas in the library  including <A
      coord="0,0,30,30" href="reference.html">Reference</A> and
      <A coords="34,34,100,100" href="media.html"> the Audio
      Visual Lab</A>.  More text can follow or precede.
      </OBJECT>
    * 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 method #4
      above). 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 so.

  * [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 (usually a graphical
    button). For example, <A HREF= "home.html" title="XYZ
    company home page"><IMG SRC="logo.gif" alt="XYZ logo"></A>

Recommendations for user agent (browser) designers

  * Calculate the alt-text for the IMG element if not provided
    by the author.
    When an author does not set the alt attribute for the IMG
    element, user agents should supply the alternate text,
    calculated in the following order:
    * If the title has been specified, its value should be used
      as alternate text.
    * Otherwise, if HTTP headers provide title information when
      the included object is retrieved, this information should
      be used as alternate text.
    * Otherwise, if the included object contains text fields
      (e.g., Portable Network Graphics (PNG) images contain some
      text fields), information extracted from the text fields
      should be used as alternate text. Since user agents may
      have to retrieve an entire object first in order to
      extract textual information, user agents may adopt more
      economical approaches (e.g., content negotiation).
    * Otherwise, in the absence of other information, user
      agents should use the file name (minus the extension) as
      alternate text.

  * Alt-text that is displayed for image links should have the
    same font attributes as text links.
    If an image is a link to another page then the alt-text
    should be coded just as other text links. The most common
    coding is blue and underlined. This will ensure that users
    will be able to distinguish between decorative or
    illustrative graphics and those that are links.
  * Load and display long descriptions of graphics on command.
    While a user is on a graphic, he or she should be able to
    issue a command to pull up the long description of the
    graphic. Especially as the longdesc attribute of IMG is
    supported or descriptions are included within the graphic
    file. The description should be displayed surrounded by
    square brackets in place of the graphic. If no description
    has been specified for a graphic, the user should be
    notified of the error.


14.4 Applets

      Since there are several full-fledged programming
     languages with accessibility issues of their own, we
     leave the discussion for how to make them accessible
     to other documents. Trace recently completed a report
     commissioned by Sun to identify the accessibility
     issues with Java. For more information on what
     JavaSoft is doing about accessibility issues within
     Java, visit their Java Accessibility site at
     http://www.sun.com/tech/access.

     However, not all browsers support applets and some
     users do not want to download them because of
     bandwidth or platform constraints. Newer browsers
     support a preferences flag that allows the user to
     indicate if they wish to view applets or not.

Recommendations for page authors

  * [Required]
      Provide alternative text for all applets.
    * [Interim] <APPLET code="Press.class" width="500"
      height="500" alt="Java applet: how temperature affects
      pressure.">
      As temperature increases the molecules in the balloon...
      </APPLET>
    * [New] <OBJECT classid="Press.class" width="500"
      height="500" title="Java applet: how temperature affects
      pressure.">
      As temperature increases the molecules in the balloon...
      </OBJECT>

  * [Required]
      Provide descriptions of applets that present important
    information.
    * [Interim] Use the <APPLET> element to provide a
      description (see the previous example).  Complete text
      descriptions could be substituted for the "Hello World!"
      message.
    * [New] Use the <OBJECT> element (see the previous example).
       Complete text descriptions and other accessible objects
      (see recommendation #5) could be substituted for the
      "Hello World!" message.

  * [Required]
      If an applet gathers information, provide an alternative
    mechanism to gather the information.
    As with the previous two recommendations, an alternative
    such as a user-input form, e-mail address, phone or fax
    number could be provided within the alternative text of
    either the <APPLET> or <OBJECT> elements.

  * [Required]
      If an applet requires a user interaction (e.g. the ability
    to manipulate a physics experiment) that can not be
    duplicated in an alternative format, make the applet
    directly accessible.
    The guidelines for accomplishing this are included within
    the Java Accessibility project, and are not yet complete.

  * [Recommended]
      For applets embedded with the <OBJECT> element, provide
    alternative, accessible presentations of information within
    the <OBJECT> element body. [New]
    In HTML4.0 the <APPLET> element has been replaced by the
    <OBJECT> element. The <OBJECT> element supports nesting of
    objects for alternative  renderings. For example:
    <!-- 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>
  * [Recommended]
      Make applets keyboard operable ( using standard
    conventions).

Recommendations for user agent (browser) designers

  * Render alternatives based on user preferences.
  * Calculate the alt-text for the APPLET element if not
    provided by the author, in the same way as suggested for
    IMG.


14.5 Audio and video

     Beyond the accessibility issues, there are other
     practical issues that support following these
     guidelines. For example, users may want to print a
     transcript of the dialogue in a movie, search for a
     certain section of an audio clip via keywords, or
     search for a particular video clip using a search
     engine such as a web crawler. Associated captions and
     transcripts makes these scenarios possible. If
     descriptions are provided in text mode as well, you
     can index and search for any video information which
     is contained in the descriptions.

Recommendations for page authors

  * [Required]
      Provide a text transcript file for all information
    presented auditorally.
    A transcript is a textual representation of all dialogue,
    and audio information.

  * [Required]
      Provide descriptions of all video information in an
    auditory form.
    Audio  descriptions of video action provide additional
    information during breaks in the dialogue of a movie about
    the actions that are occurring.

  * [Required]
      Provide a separate text transcript file of all video
    descriptions.
    A text transcript of video action provides the same
    information as in recommendation #2 but in a format
    accessible to those with no audio access.

  * [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.
    * [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.

      Example - QuickTime (for Macintosh): With QuickTime you
      can add as many audio or video tracks as you wish. Users
      can then select as few or as many of the tracks as desired
      when they view the QuickTime clip. Tracks could include
      (in addition to the regular video and audio tracks):
           * A text track with captions
           * An audio track with video descriptions added
           * An additional video track with American Sign
             Language translation
           * Additional text or audio or video tracks
             spoken or signed in other languages

For more information on captioning and descriptions visit:
http://www.boston.com/wgbh/pages/ncam/currentprojects/
captionedmovies.html

    * [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.

  * TBD
      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 like 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.

  * Design Trick: Use the "TITLE" attribute to provide a brief
    description within the link to very short sounds.
    For example, <a href="mittens.wav" title="meow"></a>

Recommendations for user agent (browser) designers

  * Support time synchronized text (caption) files.
    This implies providing the support to link three files (the
    audio, the text transcript and the text synchronization
    files).
  * Provide a command to load and display the text
    transcription/description file.
  * Visually display aural alerts.
    If the device has a ShowSounds/Captions feature then this
    indicator could be tied to the ShowSounds/Caption Flag
    maintained by the system.
  * Display the title attribute of links.


15. Style Sheets

Controlling the presentation of an HTML document


15.1 Style sheets solve several issues, but only if users can
override

     Whereas most of the other areas present issues that
     create problems, style sheets is one of the few areas
     where it generates more solutions that problems.  This
     assumes that the current specification of HTML 4.0 is
     implemented as discussed in the most recent draft.

     Elements affected:  STYLE and its attribute

Recommendations for page authors

  * [Required]
      Use style sheets to position text and objects within
    pages, rather than physically marking up text and graphics
    (e.g. <B> or the "align" attribute of <IMG>) (However,
    continue to use logical elements such as STRONG, H1, etc.
    to provide semantic coding within the body of the page)
    [New]

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, print, projection, braille, and speech.
    * highlight sections of a document with font size,
      formatting or color

  * [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.

Recommendations for user agent (browser) designers

  * Allow users to select which types of media style sheets they
    want to use.
  * Allow users to override page author settings with their own
    style sheets.

Recommendations for assistive technology designers

     Perhaps one of the best developments for AT designers
     will be style sheets that work best with their
     products, especially aural style sheets.

Suggestions for users

     If you do not want to create your own style sheet, but
     would like to ensure that pages will display
     appropriately on your viewing device, you can retrieve
     a style sheet and set it as your default from one of
     the emerging libraries of style sheets.


16. Alignment, font styles, and horizontal rules


16.1 Providing additional cues with horizontal rules

     Issue: Horizontal rules (lines) visually indicate
     changes in context or highlight a section of text. For
     example, in this document we use horizontal rules
     between chapters and sections. Since screen readers do
     not usually pronounce anything for horizontal rules
     these cues changes in context go unnoticed. In this
     document we try to give as many cues to the reader as
     possible. One strategy is to use numbers to mark each
     chapter and associated section. Therefore when you
     read 16.4, then come across 17 it should be easy to
     interpret that you have just started a new chapter. To
     provide equal "warning" to the non-visual user we use
     the title attribute of the HR element.

     Element affected:  HR

Recommendations for page authors

  * Design Trick:  Use the "title" attribute on horizontal rules
    <hr title="new section">


17. Frames

Multi-view presentation of documents


17.1 Misinterpretation by screen readers and small screen users

     Issue:  Today's screen readers often view each frame
     as either a separate window or read across several of
     them as they do tables (line by line across all
     frames).  Other times, screen readers get stuck in one
     frame. Also, when multiple frames are viewed on small
     monitors it is often difficult or impossible to see
     all of the data.

     Elements affected:  FRAME, FRAMESET  and NOFRAME

Recommendations for page authors

  * [Required]
      Provide a <NOFRAME> option for each <FRAMESET>.
    When using the <NOFRAME> option it is easiest to include all
    essential information on the bottom of the main frame. The
    following example is taken from the HTML 4.0 specification.
    * If the user reads "top.html" and the user agent is not
      displaying frames the user won't see anything since we do
      not have a BODY in "top.html". If we insert
      "table_of_contents.html" and "main.html" directly in a
      NOFRAMES element in the FRAMESET, we solve the problem of
      associating the two documents, but we may cause user
      agents that support frames to retrieve the same data
      twice: one copy associated with the FRAMESET and one copy
      inserted in the NOFRAMES. It is more economical to include
      the table of contents at the top of "main.html" within a
      NOFRAMES element:

      <!-- This is main.html -->
      <HTML><BODY>
      <NOFRAMES>
      ...the table of contents here...
      </NOFRAMES>
      ...the rest of the document...
      </BODY></HTML>

      and to link to "main.html" from "top.html" for the case
      when frames are not displayed:

      <!-- This is top.html -->
      <HTML>
      <FRAMESET cols="50%, 50%" title="Our big document">
      <FRAME src="main.html" title="Where it's all at">
      <FRAME src="table_of_contents.html" title="Table of
      Contents">
      <NOFRAMES>
      Here's the <A href="main.html">for a non-frames
      version.</A>
      </NOFRAMES>
      </FRAMESET>
      </HTML>

  * [Recommended]
    Title each frame. [TOMORROW]
    Notice the use of "TITLE" in the previous example. People
    accesing the page aurally will more easily keep track of how
    many frames exist and which is the current one.

Recommendations for user agent (browser) designers

     Allow the user to select whether they want to load
     frames or not.  If they do not, use the NOFRAME option
     provided by the page author or the first frame defined
     as default.

Recommendations for assistive technology designers

     Screen readers should be able to navigate each frame
     as a separate window that is identified uniquely by
     the TITLE of each frame.

Suggestions for users

     If you don't want to view frames, select the "NOFRAME"
     in your user agent (TOMORROW), or use a text-based
     like Lynx which automatically requests the NOFRAME
     (TODAY).


 18. Forms

User-input Forms: Text Fields, Buttons, Menus, and more

  * 18.1 Navigation and manipulation
  * 18.2 Graphical buttons


18.1 Navigation and manipulation

     Issue:  Users who do not use a mouse (such as screen
     reader users) or that do not use a mouse well (such as
     users with mobility disabilities) are not always able
     to navigate into form elements. Often, once they are
     able to focus on the form element they are unable to
     manipulate it.

     Elements affected:  A, AREA, OBJECT, INPUT, SELECT,
     TEXTAREA, and BUTTON.

Recommendations for page authors

  * [Required]
      Explicitly associate labels with their control. [New]
    For example:
    <FORM action="http://somesite.com/adduser" method="post"
    <FIELDSET>
    <LEGEND align="top">Personal information</LEGEND>
    <LABEL for="firstname">First name: </LABEL>
    <INPUT type="text" id="firstname" tabindex="1">
    <LABEL for="lastname">Last name: </LABEL>
    <INPUT type="text" id="lastname" tabindex="2">
    ...more personal information...
    </FIELDSET>
    <FIELDSET>
    <LEGEND align="top">Medical History</LEGEND>
    ...medical history information...
    </FIELDSET>
    </FORM>
  * [Recommended]
      Specify a logical tab order with "tabindex".[New]
    For example, (taken from the HTML 4.0 draft)
    <INPUT tabindex="1" type="text" name="field1">
    <INPUT tabindex="2" type="text" name="field2">
    <INPUT tabindex="3" type="submit" name="submit">
  * [Recommended]
      Group related controls with the <FIELDSET> element.[New]
    see the example for #2 - "Explicitly associate labels with
    their control."
  * [Recommended]
      Label a group of controls with the <LEGEND> element. [New]
    see the example for #2 - "Explicitly associate labels with
    their control."
  * [Recommended]
      Include default, place-holding characters in edit boxes
    and text areas. [Interim]
  * [Recommended]
      Include a phone number, e-mail address, postal address or
    fax number for submitting information.
  * [Recommended]
      Create keyboard shortcuts for form elements. [New]
    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>

Recommendations for user agent (browser) designers

  * Support the accesskey attribute and FIELDSET and LEGEND
    elements included in the HTML 4.0 specification.
  * Allow users to navigate to and manipulate all form elements
    via the keyboard.
  * Calculate the alt-text for the INPUT element if not provided
    by the author.
    When an author does not set the alt attribute for the INPUT
    element, user agents should supply the alternate text,
    calculated in the following order:
    * If the title has been specified, its value should be used
      as alternate text.
    * Otherwise, if the name has been specified, its value
      should be used as alternate text.
    * Otherwise (submit and reset buttons), the value of the
      type attribute should be used as alternate text

  * Read labels with their associated objects.


18.2 Graphical buttons

     Issue:  Forms can include images that act as buttons
     or image maps to gather input.  See the section that
     discusses graphical links.

Recommendations for page authors

  * [Required]
      Do not use image maps to create graphical "submit" buttons.
  * [Required]
      Provide alternative text for images used as "submit"
    buttons.
    For example, <INPUT type="image" name="submit"
    src="button.gif" alt="Submit">


19. Scripts

Animated Documents and Smart Forms

  * 19.1 Introduction to the issues
    * 19.1.1 Action occurring away from user focus
    * 19.1.2 Actions executed during load of page
    * 19.1.3 Automatic update of page ("push")
    * 19.1.4 Summary of issues


19.1 Introduction to the issues

     A client-side script is a program that may accompany
     an HTML document or be embedded directly in it. The
     program executes on the client's machine when the
     document loads, or at some other time such as when a
     link is activated. HTML's support for scripts is
     independent of the scripting language.

     Scripts offer authors a means to extend HTML documents
     in highly active and interactive ways. For example:
       * Scripts may be evaluated as a document loads to
         modify the contents of the document dynamically.
       * Scripts may accompany a form to process input as
         it is entered. Designers may dynamically fill out
         parts of a form based on the values of other
         fields. They may also ensure that input data
         conforms to predetermined ranges of values, that
         fields are mutually consistent, etc.
       * Scripts may be triggered by events that affect the
         document, such as loading, unloading, element
         focus, mouse movement, etc.
       * Scripts may be linked to form controls (e.g.,
         buttons) to produce graphical user interface
         elements (HTML 4.0 draft).

19.1.1 Action occurring away from user focus

     Issue: "Intrinsic events" are events generated by the
     elements on an HTML page that can be used to trigger
     scripts that accompany a page. These scripts are often
     used to cause action away from the user focus.  Where
     the user's focus is limited because they are accessing
     the page aurally or only accessing a portion of the
     page (via a PDA or screen magnification), these events
     may go unnoticed.  Intrinsic events are:  onfocus,
     onblur, onchange, onclick, ondblclick, onmousedown,
     onmouseup, onmouseover, onmousemove, onmouseout,
     onkeypress, onkeydown, onkeyup.

19.1.2 Actions executed during load of page

     Issue: There are two types of scripts: those that are
     execute in conjunction with an intrinsic event (just
     discussed) and those executed during loading or
     immediately after the page is loaded. This includes
     audio greetings that are played upon opening a page.
     For this example, if valuable information about how to
     navigate the site is exclusively delivered by audio,
     people who are unable to hear the greeting will miss
     out on the instructions.

19.1.3 Automatic update of page ("push")

     Issue :  Where an intrinsic event or an allotted
     passage of time causes another page to be loaded or
     more information to be displayed, a user who has a
     limited focus may not realize new information has been
     displayed.  For example, if they are reading a page of
     basketball scores line by line with a screen reader,
     by the time they have read one score of one game, the
     page may have reloaded a different set of scores.  In
     this case they would hear one score for each team for
     two different games. Not all users are able to
     interact with animations or dynamically changing pages
     either because they are not able to position and
     activate the mouse quickly enough, or do not have the
     visual information to realize that the page is
     changing.

19.1.4  Summary of issues

  * Where the user's focus is limited because they are accessing
    the page aurally or only accessing a portion of the page
    (via a PDA or screen magnification), events occurring away
    from the center of the user's focus may go unnoticed.
  * Actions executed during loading or immediately after the
    page is loaded may go unnoticed.
  * Where an intrinsic event or an allotted passage of time
    causes another page to be loaded or more information to be
    displayed, a user with a limited focus may not realize new
    information has been displayed.
  * Not all users are able to interact with animations or
    dynamically changing pages either because they are not quick
    enough, do not have the visual information to realize that
    the page is changing, or do not have the agility to
    precisely select a moving image.

Elements affected:  almost every element generates at least one
of the intrinsic events

Recommendations for page authors

  * [Required]
      Provide a <NOSCRIPT> option for all 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>
  * [Required]
      Provide a mechanism for the user to freeze any moving or
    blinking text.
  * More exploration is needed in this area. Please stay tuned.

Recommendations for user agent (browser) designers

  * Provide the ability to pause "pushes" until the user is
    ready for them.
  * Provide information in the status line to let users know
    that the page is updating or changing.
  * Provide the ability to break out the text of an animation,
    banner or etc. and present it as static text.


20. [Place holder for "SGML reference information for HTML"]

21. [Place holder for "SGML Declaration"]

22. [Place holder for "Document Type Definition']

23. [Place holder for "Transitional Document Type Definition']

24. [Place holder for "Frameset Document Type Definition"]

25. [Place holder for "Named character entities"]


26. Structure and Navigation of web sites


Now that each individual page is accessible, there are few
things to consider about your site as a whole.

  * Page layout is consistent but pages or areas do not look
    identical.
    For example, navigation bars should be located in the same
    place on every page.
  * A clear, consistent navigation structure is used.
    You should always be able to easily navigate to all
    documents which immediately relate, but you should also
    always be able to get any other document in the
    infrastructure with a minimum of fuss. Always provide access
    to the original table of contents, or its equivalent. This
    is especially important when others create links to
    documents in your site that are not necessarily main entry
    points.  This will prevent readers from finding themselves
    in the middle of what is obviously a larger document, but
    without any means of finding additional information.
  * Navigation bars provide easy access to the navigation
    structure.
    Graphical aids are useful for some persons with learning or
    intellectual disabilities.  The button bar can be individual
    .GIF files or an image map. BUT don't forget to provide
    alternatives for users who cannot view graphics.  It is
    helpful to keep the same buttons and the same location on
    every page.
  * Instructions are provided to describe the general layout of
    the site, the access features used, and how to use them.
    For example, if you use D-links describe what information
    the user can expect to find when following D-links.
  * A site map is available.
    People who have difficulty visualizing the structure of
    information can be helped by a site map, a visualization of
    the structure of the site. In the future, perhaps user
    agents will update the view of the site map with the path of
    navigation and the location of the current page.
  * Different types of searches are available for different
    skill levels and preferences.
    Most search facilities require the user to enter keywords
    for search terms. Users with spelling disabilities and
    foreign users will have a difficult time finding what they
    need as long as perfect spellings are required. Search
    engines could include a spell checker, offering best guess
    alternatives or offer different types of searches, for
    example: query-by-example or similarity searches.
  * Nothing within the site prevents keyboard operation.
  * Elements outside of the HTML 4.0 specification (such as
    <BLINK> and <MARQUEE>) are not used
  * Use a design tool that supports access features (and does
    not remove access when you close, or reopen your page using
    the tool)
  * Test the site with AT LEAST:
    * a text only browser (such as Lynx)
    * a self-voicing browser (such as PWWebspeak)
    * Multiple graphic browsers, with:
      * sounds and graphics loaded,
      * graphics not loaded,
      * sounds not loaded,
      * no mouse


Appendices


A. Design Notes

Alt-text Tips and Tricks

  * Keep the wording simple.
  * Sometimes it is easier to describe what the function of the
    graphic is rather than what it is or looks like.
  * Using the height & width attributes for images may cause the
    alt-text to wrap, which often makes it unreadable by
    everyone but Lynx users. By decreasing the size of the font,
    the alt-text can be made to fit in the specified region.
  * Include periods at the end of alt-text of images, especially
    those used as links. Periods cause screen readers to pause
    and will give an indication of where the alt-text ends and
    the rest of the text begins. It also ensures that several
    links in a row will not be strung together into a single
    link.
  * Graphical lines can be used to provide extra cues for
    changes in context, in comparison with the<HR> element. For
    example, the alt-text for a graphical line might be 'Section
    2: today's weather."
  * For critical bullets, use numbers or letters as the alt-text
    so that they are pronounced.
  * One of the first items a user encounters on the site should
    be a description of what protocol is being used. For
    example, make it clear that images that have spaces for
    alt-text or not alt-text at all are not required to grasp
    the content of the page.
  * AT&T has created a reference area for creating alt-text
    available at http://www.att.com/style/alttext.html


Methods to create alternate pages

  * "By hand"
    Sometimes, a site may only need to create text-only pages
    for layouts that can not be made accessible. This may
    involve only a couple of pages.
  * Database-based pages:
    Create a database-based server that generates HTML pages on
    demand when the user asks for them. In this manner, pages
    can be constructed "on the fly" either with or without
    graphics. An example of this is the the CommerceNet server.
  * Filters
    This approach is similar to Database-based pages, but
    involves the use of a filter/translator that would exist on
    the server as a common gateway interface (cgi). Pages would
    be constructed using alt-text and alternate text pages where
    needed and, at the direction of the user, be translated into
    either graphic or pure text pages on the fly. This method
    has disadvantages however. Since all pages must be processed
    on the fly (as with the database method), there may be a
    decrement in performance unless the filter program is used
    off-line to create the text versions of the pages in
    advance. Secondly, this method would only work for pages on
    the server with the AltPage cgi. Whenever references were
    made to other pages on other servers, the filter would not
    work. Image maps on other servers would be a particular
    problem unless client-side image maps were used. Finally,
    such a filter would create text versions of pages, but since
    it would do so by formula, the pages may not be laid out
    very well or be very easy to interpret. Building access into
    the page or providing alternate pages which are laid out to
    make sense in text form (and to provide a text alternative
    to any Image Maps) as with 1 (By hand) would be much more
    effective.
  * Style sheets


References

  * HTML 4.0 draft Available:
    http://www.w3.org/TR/WD-html40/cover.html
  * World Wide Web browser access recommendations - Jon
    Gunderson. Available:
    http://www.staff.uiuc.edu/~jongund/access-browsers.html

Designing Accessible HTML Pages -- guidelines and overview
documents

  * Accessible Design for Users with Disabilities. -- Sun
    Microsystems
  * The Accessible Web: Web Access Through Adaptive Technology
    -- Kevin Nguyen, University of Toronto
  * ACT Centre Accessible Web Design
  * All Things Web
  * ALT text recommendations, and notes on viewing situation --
    A.J. Flavell, University of Glasgow
  * Alternative Access to the World Wide Web -- University of
    Toronto
  * Any Browser Table Format -- Department of MIssions, Abilene
    Christian University
  * Best Viewed With Any Browser -- Accessible Site Design
  * Compatibility & Accessibility -- Towards the creation of an
    accessible, truly World-wide Web -- All Things Web
  * Composing Good HTML -- James "Eric" Tilton.
  * Design Considerations: Readers with Visual Impairments --
    Arthur R. Murphy
  * Designing Access to WWW Pages - Alliance for Technology
    Access.
  * Designing HTML Tables to Work with HTML 2.0 Browsers --
    Stanton McCandlish
  * DO-IT HTML Guidelines -- University of Washington
  * Experiences Implementing Web Accessibility Guidelines in IBM
    -- Phill Jenkins
  * For Web Page Designers -- Microsoft
  * GSA HTML Accessibility Guidelines - Paul Fontaine
  * Guide to Writing Accessible HTML -- University of Toronto
  * Guidelines on Universal Web-Site Accessibility -- Treasury
    Board Internet Working Group on Internet Presentation, Style
    and Accessibility
  * Hints for designing accessible Websites -- Royal National
    Institute for the Blind
  * IBM Web Design Guidelines
  * Increasing Access to World Wide Web Sites for Blind and
    Visually Impaired Computer Users -- Dena Shumila, Jan
    Richards
  * InfoUse Web Accessibility Guidelines
  * 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
  * The Lynx Manifesto -- Dehanced for Lynx
  * Making Your Site Speech Friendly -- Cathy Anne Murtha, Web
    Design and Access Specialist, Magical Mist Creations
  * NCSA Mosaic Access Page
  * Nimble Document Navigation Using Alternative Access Tools --
    Jutta Treviranus, University of Toronto
  * On-Line Examples of HTML Accessibility - Chuck Le Tourneau
  * Tables on non-table browsers -- A.J. Flavell, Glasgow
    University
  * Unified HTML Accessibility Guidelines -- Previous version of
    this document
  * Universal Accessibility -- Government of Canada Internet
    Guide
  * Universal Design of WWW Pages -- a DO-IT (University of
    Washington) Brochure
  * Universal Information Access on the WWW (COCA)
  * "Universal Specifications" Accessibility Standards for Web
    Design -- New South Wales Attorney General's Department
  * Usability of Information and the WWW -- UCLA Disabilities
    and Computing Program
  * Web Accessibility Guidelines -- IBM
  * World Wide Web Access: Disability Discrimination Act
    Advisory Notes -- Australia

----------
End of Document