[contents]   [checklist]
     _________________________________________________________________
   
   W3C 
   
Web Content Accessibility Guidelines 1.0

W3C Recommendation 5-May-1999

   This version:
          http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505
          (plain text, PostScript, PDF, gzip tar file of HTML, zip
          archive of HTML)
          
   Latest version:
          http://www.w3.org/TR/WAI-WEBCONTENT
          
   Previous version:
          http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990324
          
   Editors:
          Wendy Chisholm, Trace R & D Center, University of Wisconsin --
          Madison
          Gregg Vanderheiden, Trace R & D Center, University of Wisconsin
          -- Madison
          Ian Jacobs, W3C
          
   Copyright © 1999 W3C (MIT, INRIA, Keio), All Rights Reserved. W3C
   liability, trademark, document use and software licensing rules
   apply.
     _________________________________________________________________
   
Abstract

   These guidelines explain how to make Web content accessible to people
   with disabilities. The guidelines are intended for all Web content
   developers (page authors and site designers) and for developers of
   authoring tools. The primary goal of these guidelines is to promote
   accessibility. However, following them will also make Web content more
   available to all users, whatever user agent they are using (e.g.,
   desktop browser, voice browser, mobile phone, automobile-based
   personal computer, etc.) or constraints they may be operating under
   (e.g., noisy surroundings, under- or over-illuminated rooms, in a
   hands-free environment, etc.). Following these guidelines will also
   help people find information on the Web more quickly. These guidelines
   do not discourage content developers from using images, video, etc.,
   but rather explain how to make multimedia content more accessible to a
   wide audience.
   
   This is a reference document for accessibility principles and design
   ideas. Some of the strategies discussed in this document address
   certain Web internationalization and mobile access concerns. However,
   this document focuses on accessibility and does not fully address the
   related concerns of other W3C Activities. Please consult the W3C
   Mobile Access Activity home page and the W3C Internationalization
   Activity home page for more information.
   
   This document is meant to be stable and therefore does not provide
   specific information about browser support for different technologies
   as that information changes rapidly. Instead, the Web Accessibility
   Initiative (WAI) Web site provides such information (refer to
   [WAI-UA-SUPPORT]).
   
   This document includes an appendix that organizes all of the
   checkpoints by topic and priority. The checkpoints in the appendix
   link to their definitions in the current document. The topics
   identified in the appendix include images, multimedia, tables, frames,
   forms, and scripts. The appendix is available as either a tabular
   summary of checkpoints or as a simple list of checkpoints.
   
   A separate document, entitled "Techniques for Web Content
   Accessibility Guidelines 1.0" ([TECHNIQUES]), explains how to
   implement the checkpoints defined in the current document. The
   Techniques Document discusses each checkpoint in more detail and
   provides examples using the Hypertext Markup Language (HTML),
   Cascading Style Sheets (CSS), Synchronized Multimedia Integration
   Language (SMIL), and the Mathematical Markup Language (MathML). The
   Techniques Document also includes techniques for document validation
   and testing, and an index of HTML elements and attributes (and which
   techniques use them). The Techniques Document has been designed to
   track changes in technology and is expected to be updated more
   frequently than the current document. Note. Not all browsers or
   multimedia tools may support the features described in the guidelines.
   In particular, new features of HTML 4.0 or CSS 1 or CSS 2 may not be
   supported.
   
   "Web Content Accessibility Guidelines 1.0" is part of a series of
   accessibility guidelines published by the Web Accessibility
   Initiative. The series also includes User Agent Accessibility
   Guidelines ([WAI-USERAGENT]) and Authoring Tool Accessibility
   Guidelines ([WAI-AUTOOLS]).
   
Status of this document

   This document has been reviewed by W3C Members and other interested
   parties and has been endorsed by the Director as a W3C Recommendation.
   It is a stable document and may be used as reference material or cited
   as a normative reference from another documents. W3C's role in making
   the Recommendation is to draw attention to the specification and to
   promote its widespread deployment. This enhances the functionality and
   universality of the Web.
   
   The English version of this specification is the only normative
   version. However, for translations in other languages see
   http://www.w3.org/WAI/GL/WAI-WEBCONTENT-TRANSLATIONS.
   
   The list of known errors in this document is available at
   http://www.w3.org/WAI/GL/WAI-WEBCONTENT-ERRATA. Please report errors
   in this document to wai-wcag-editor@w3.org.
   
   A list of current W3C Recommendations and other technical documents
   can be found at http://www.w3.org/TR.
   
   This document has been produced as part of the W3C Web Accessibility
   Initiative. The goal of the Web Content Guidelines Working Group is
   discussed in the Working Group charter.
   
Table of Contents

     * Abstract
     * Status of this document
     * 1. Introduction
     * 2. Themes of Accessible Design
          + 2.1 Ensuring Graceful Transformation
          + 2.2 Making Content Understandable and Navigable
     * 3. How the Guidelines are Organized
          + 3.1 Document conventions
     * 4. Priorities
     * 5. Conformance
     * 6. Web Content Accessibility Guidelines
          + 1. Provide equivalent alternatives to auditory and visual
            content.
          + 2. Don't rely on color alone.
          + 3. Use markup and style sheets and do so properly.
          + 4. Clarify natural language usage
          + 5. Create tables that transform gracefully.
          + 6. Ensure that pages featuring new technologies transform
            gracefully.
          + 7. Ensure user control of time-sensitive content changes.
          + 8. Ensure direct accessibility of embedded user interfaces.
          + 9. Design for device-independence.
          + 10. Use interim solutions.
          + 11. Use W3C technologies and guidelines.
          + 12. Provide context and orientation information.
          + 13. Provide clear navigation mechanisms.
          + 14. Ensure that documents are clear and simple.
     * Appendix A. -- Validation
     * Appendix B. -- Glossary 
     * Acknowledgments
     * References
       
   The appendix list of checkpoints is available as either a tabular
   summary of checkpoints or as a simple list of checkpoints.
     _________________________________________________________________
   
1. Introduction

   For those unfamiliar with accessibility issues pertaining to Web page
   design, consider that many users may be operating in contexts very
   different from your own:
     * They may not be able to see, hear, move, or may not be able to
       process some types of information easily or at all.
     * They may have difficulty reading or comprehending text.
     * They may not have or be able to use a keyboard or mouse.
     * They may have a text-only screen, a small screen, or a slow
       Internet connection.
     * They may not speak or understand fluently the language in which
       the document is written.
     * They may be in a situation where their eyes, ears, or hands are
       busy or interfered with (e.g., driving to work, working in a loud
       environment, etc.).
     * They may have an early version of a browser, a different browser
       entirely, a voice browser, or a different operating system.
       
   Content developers must consider these different situations during
   page design. While there are several situations to consider, each
   accessible design choice generally benefits several disability groups
   at once and the Web community as a whole. For example, by using style
   sheets to control font styles and eliminating the FONT element, HTML
   authors will have more control over their pages, make those pages more
   accessible to people with low vision, and by sharing the style sheets,
   will often shorten page download times for all users.
   
   The guidelines discuss accessibility issues and provide accessible
   design solutions. They address typical scenarios (similar to the font
   style example) that may pose problems for users with certain
   disabilities. For example, the first guideline explains how content
   developers can make images accessible. Some users may not be able to
   see images, others may use text-based browsers that do not support
   images, while others may have turned off support for images (e.g., due
   to a slow Internet connection). The guidelines do not suggest avoiding
   images as a way to improve accessibility. Instead, they explain that
   providing a text equivalent of the image will make it accessible.
   
   How does a text equivalent make the image accessible? Both words in
   "text equivalent" are important:
     * Text content can be presented to the user as synthesized speech,
       braille, and visually-displayed text. Each of these three
       mechanisms uses a different sense -- ears for synthesized speech,
       tactile for braille, and eyes for visually-displayed text --
       making the information accessible to groups representing a variety
       of sensory and other disabilities.
     * In order to be useful, the text must convey the same function or
       purpose as the image. For example, consider a text equivalent for
       a photographic image of the Earth as seen from outer space. If the
       purpose of the image is mostly that of decoration, then the text
       "Photograph of the Earth as seen from outer space" might fulfill
       the necessary function. If the purpose of the photograph is to
       illustrate specific information about world geography, then the
       text equivalent should convey that information. If the photograph
       has been designed to tell the user to select the image (e.g., by
       clicking on it) for information about the earth, equivalent text
       would be "Information about the Earth". Thus, if the text conveys
       the same function or purpose for the user with a disability as the
       image does for other users, then it can be considered a text
       equivalent.
       
   Note that, in addition to benefitting users with disabilities, text
   equivalents can help all users find pages more quickly, since search
   robots can use the text when indexing the pages.
   
   While Web content developers must provide text equivalents for images
   and other multimedia content, it is the responsibility of user agents
   (e.g., browsers and assistive technologies such as screen readers,
   braille displays, etc.) to present the information to the user.
   
   Non-text equivalents of text (e.g., icons, pre-recorded speech, or a
   video of a person translating the text into sign language) can make
   documents accessible to people who may have difficulty accessing
   written text, including many individuals with cognitive disabilities,
   learning disabilities, and deafness. Non-text equivalents of text can
   also be helpful to non-readers. An auditory description is an example
   of a non-text equivalent of visual information. An auditory
   description of a multimedia presentation's visual track benefits
   people who cannot see the visual information.
   
2. Themes of Accessible Design

   The guidelines address two general themes: ensuring graceful
   transformation, and making content understandable and navigable.
   
  2.1 Ensuring Graceful Transformation
  
   By following these guidelines, content developers can create pages
   that transform gracefully. Pages that transform gracefully remain
   accessible despite any of the constraints described in the
   introduction, including physical, sensory, and cognitive
   disabilities, work constraints, and technological barriers. Here are
   some keys to designing pages that transform gracefully:
     * Separate structure from presentation (refer to the difference
       between content, structure, and presentation).
     * Provide text (including text equivalents). Text can be rendered in
       ways that are available to almost all browsing devices and
       accessible to almost all users.
     * Create documents that work even if the user cannot see and/or
       hear. Provide information that serves the same purpose or function
       as audio or video in ways suited to alternate sensory channels as
       well. This does not mean creating a prerecorded audio version of
       an entire site to make it accessible to users who are blind. Users
       who are blind can use screen reader technology to render all text
       information in a page.
     * Create documents that do not rely on one type of hardware. Pages
       should be usable by people without mice, with small screens, low
       resolution screens, black and white screens, no screens, with only
       voice or text output, etc.
       
   The theme of graceful transformation is addressed primarily by
   guidelines 1 to 11.
   
  2.2 Making Content Understandable and Navigable
  
   Content developers should make content understandable and navigable.
   This includes not only making the language clear and simple, but also
   providing understandable mechanisms for navigating within and between
   pages. Providing navigation tools and orientation information in pages
   will maximize accessibility and usability. Not all users can make use
   of visual clues such as image maps, proportional scroll bars,
   side-by-side frames, or graphics that guide sighted users of graphical
   desktop browsers. Users also lose contextual information when they can
   only view a portion of a page, either because they are accessing the
   page one word at a time (speech synthesis or braille display), or one
   section at a time (small display, or a magnified display). Without
   orientation information, users may not be able to understand very
   large tables, lists, menus, etc.
   
   The theme of making content understandable and navigable is addressed
   primarily in guidelines 12 to 14.
   
3. How the Guidelines are Organized

   This document includes fourteen guidelines, or general principles of
   accessible design. Each guideline includes:
     * The guideline number.
     * The statement of the guideline.
     * Guideline navigation links. Three links allow navigation to the
       next guideline (right arrow icon), the previous guideline (left
       arrow icon), or the current guideline's position in the table of
       contents (up arrow icon).
     * The rationale behind the guideline and some groups of users who
       benefit from it.
     * A list of checkpoint definitions.
       
   The checkpoint definitions in each guideline explain how the guideline
   applies in typical content development scenarios. Each checkpoint
   definition includes:
     * The checkpoint number.
     * The statement of the checkpoint.
     * The priority of the checkpoint. Priority 1 checkpoints are
       highlighted through the use of style sheets.
     * Optional informative notes, clarifying examples, and cross
       references to related guidelines or checkpoints.
     * A link to a section of the Techniques Document ([TECHNIQUES])
       where implementations and examples of the checkpoint are
       discussed.
       
   Each checkpoint is intended to be specific enough so that someone
   reviewing a page or site may verify that the checkpoint has been
   satisfied.
   
  3.1 Document conventions
  
   The following editorial conventions are used throughout this document:
     * Element names are in uppercase letters.
     * Attribute names are quoted in lowercase letters.
     * Links to definitions are highlighted through the use of style
       sheets.
       
4. Priorities

   Each checkpoint has a priority level assigned by the Working Group
   based on the checkpoint's impact on accessibility.
   
   [Priority 1]
          A Web content developer must satisfy this checkpoint.
          Otherwise, one or more groups will find it impossible to access
          information in the document. Satisfying this checkpoint is a
          basic requirement for some groups to be able to use Web
          documents.
          
   [Priority 2]
          A Web content developer should satisfy this checkpoint.
          Otherwise, one or more groups will find it difficult to access
          information in the document. Satisfying this checkpoint will
          remove significant barriers to accessing Web documents.
          
   [Priority 3]
          A Web content developer may address this checkpoint. Otherwise,
          one or more groups will find it somewhat difficult to access
          information in the document. Satisfying this checkpoint will
          improve access to Web documents.
          
   Some checkpoints specify a priority level that may change under
   certain (indicated) conditions.
   
5. Conformance

   This section defines three levels of conformance to this document:
     * Conformance Level "A": all Priority 1 checkpoints are satisfied;
     * Conformance Level "Double-A": all Priority 1 and 2 checkpoints are
       satisfied;
     * Conformance Level "Triple-A": all Priority 1, 2, and 3 checkpoints
       are satisfied;
       
   Note. Conformance levels are spelled out in text so they may be
   understood when rendered to speech.
   
   Claims of conformance to this document must use one of the following
   two forms.
   
   Form 1: Specify:
     * The guidelines title: "Web Content Accessibility Guidelines 1.0"
     * The guidelines URI:
       http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505
     * The conformance level satisfied: "A", "Double-A", or "Triple-A".
     * The scope covered by the claim (e.g., page, site, or defined
       portion of a site.).
       
   Example of Form 1:
   
     This page conforms to W3C's "Web Content Accessibility Guidelines
     1.0", available at
     http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505, level Double-A.
     
   Form 2: Include, on each page claiming conformance, one of three icons
   provided by W3C and link the icon to the appropriate W3C explanation
   of the claim. Information about the icons and how to insert them in
   pages is available at [WCAG-ICONS].
     _________________________________________________________________
   
6. Web Content Accessibility Guidelines

  Guideline 1. Provide equivalent alternatives to auditory and visual content.
  
   Next guideline: 2 Previous guideline: 14 Go to contents 
   
    Provide content that, when presented to the user, conveys essentially the
    same function or purpose as auditory or visual content.
    
   Although some people cannot use images, movies, sounds, applets, etc.
   directly, they may still use pages that include equivalent information
   to the visual or auditory content. The equivalent information must
   serve the same purpose as the visual or auditory content. Thus, a text
   equivalent for an image of an upward arrow that links to a table of
   contents could be "Go to table of contents". In some cases, an
   equivalent should also describe the appearance of visual content
   (e.g., for complex charts, billboards, or diagrams) or the sound of
   auditory content (e.g., for audio samples used in education).
   
   This guideline emphasizes the importance of providing text equivalents
   of non-text content (images, pre-recorded audio, video). The power of
   text equivalents lies in their capacity to be rendered in ways that
   are accessible to people from various disability groups using a
   variety of technologies. Text can be readily output to speech
   synthesizers and braille displays, and can be presented visually (in a
   variety of sizes) on computer displays and paper. Synthesized speech
   is critical for individuals who are blind and for many people with the
   reading difficulties that often accompany cognitive disabilities,
   learning disabilities, and deafness. Braille is essential for
   individuals who are both deaf and blind, as well as many individuals
   whose only sensory disability is blindness. Text displayed visually
   benefits users who are deaf as well as the majority of Web users.
   
   Providing non-text equivalents (e.g., pictures, videos, and
   pre-recorded audio) of text is also beneficial to some users,
   especially nonreaders or people who have difficulty reading. In movies
   or visual presentations, visual action such as body language or other
   visual cues may not be accompanied by enough audio information to
   convey the same information. Unless verbal descriptions of this visual
   information are provided, people who cannot see (or look at) the
   visual content will not be able to perceive it.
   
    Checkpoints:
    
   1.1 Provide a text equivalent for every non-text element (e.g., via
          "alt", "longdesc", or in element content). This includes:
          images, graphical representations of text (including symbols),
          image map regions, animations (e.g., animated GIFs), applets
          and programmatic objects, ascii art, frames, scripts, images
          used as list bullets, spacers, graphical buttons, sounds
          (played with or without user interaction), stand-alone audio
          files, audio tracks of video, and video. [Priority 1]
          For example, in HTML:
          
          + Use "alt" for the IMG, INPUT, and APPLET elements, or provide
            a text equivalent in the content of the OBJECT and APPLET
            elements.
          + For complex content (e.g., a chart) where the "alt" text does
            not provide a complete text equivalent, provide an additional
            description using, for example, "longdesc" with IMG or FRAME,
            a link inside an OBJECT element, or a description link.
          + For image maps, either use the "alt" attribute with AREA, or
            use the MAP element with A elements (and other text) as
            content.
            
          Refer also to checkpoint 9.1 and checkpoint 13.10.
          
          Techniques for checkpoint 1.1
          
   1.2 Provide redundant text links for each active region of a
          server-side image map. [Priority 1]
          Refer also to checkpoint 1.5 and checkpoint 9.1.
          Techniques for checkpoint 1.2
          
   1.3 Until user agents can automatically read aloud the text equivalent
          of a visual track, provide an auditory description of the
          important information of the visual track of a multimedia
          presentation. [Priority 1]
          Synchronize the auditory description with the audio track as
          per checkpoint 1.4. Refer to checkpoint 1.1 for information
          about textual equivalents for visual information.
          Techniques for checkpoint 1.3
          
   1.4 For any time-based multimedia presentation (e.g., a movie or
          animation), synchronize equivalent alternatives (e.g., captions
          or auditory descriptions of the visual track) with the
          presentation. [Priority 1]
          Techniques for checkpoint 1.4
          
   1.5 Until user agents render text equivalents for client-side image
          map links, provide redundant text links for each active region
          of a client-side image map. [Priority 3]
          Refer also to checkpoint 1.2 and checkpoint 9.1.
          Techniques for checkpoint 1.5
          
  Guideline 2. Don't rely on color alone.
  
   Next guideline: 3 Previous guideline: 1 Go to contents 
   
    Ensure that text and graphics are understandable when viewed without color.
    
   If color alone is used to convey information, people who cannot
   differentiate between certain colors and users with devices that have
   non-color or non-visual displays will not receive the information.
   When foreground and background colors are too close to the same hue,
   they may not provide sufficient contrast when viewed using monochrome
   displays or by people with different types of color deficits.
   
    Checkpoints:
    
   2.1 Ensure that all information conveyed with color is also available
          without color, for example from context or markup. [Priority 1]
          Techniques for checkpoint 2.1
          
   2.2 Ensure that foreground and background color combinations provide
          sufficient contrast when viewed by someone having color
          deficits or when viewed on a black and white screen.
          [Priority 2 for images, Priority 3 for text].
          Techniques for checkpoint 2.2
          
  Guideline 3. Use markup and style sheets and do so properly.
  
   Next guideline: 4 Previous guideline: 2 Go to contents 
   
    Mark up documents with the proper structural elements. Control presentation
    with style sheets rather than with presentation elements and attributes.
    
   Using markup improperly -- not according to specification -- hinders
   accessibility. Misusing markup for a presentation effect (e.g., using
   a table for layout or a header to change the font size) makes it
   difficult for users with specialized software to understand the
   organization of the page or to navigate through it. Furthermore, using
   presentation markup rather than structural markup to convey structure
   (e.g., constructing what looks like a table of data with an HTML PRE
   element) makes it difficult to render a page intelligibly to other
   devices (refer to the description of difference between content,
   structure, and presentation).
   
   Content developers may be tempted to use (or misuse) constructs that
   achieve a desired formatting effect on older browsers. They must be
   aware that these practices cause accessibility problems and must
   consider whether the formatting effect is so critical as to warrant
   making the document inaccessible to some users.
   
   At the other extreme, content developers must not sacrifice
   appropriate markup because a certain browser or assistive technology
   does not process it correctly. For example, it is appropriate to use
   the TABLE element in HTML to mark up tabular information even though
   some older screen readers may not handle side-by-side text correctly
   (refer to checkpoint 10.3). Using TABLE correctly and creating tables
   that transform gracefully (refer to guideline 5) makes it possible for
   software to render tables other than as two-dimensional grids.
   
    Checkpoints:
    
   3.1 When an appropriate markup language exists, use markup rather than
          images to convey information. [Priority 2]
          For example, use MathML to mark up mathematical equations, and
          style sheets to format text and control layout. Also, avoid
          using images to represent text -- use text and style sheets
          instead. Refer also to guideline 6 and guideline 11.
          Techniques for checkpoint 3.1
          
   3.2 Create documents that validate to published formal grammars.
          [Priority 2]
          For example, include a document type declaration at the
          beginning of a document that refers to a published DTD (e.g.,
          the strict HTML 4.0 DTD).
          Techniques for checkpoint 3.2
          
   3.3 Use style sheets to control layout and presentation. [Priority 2]
          For example, use the CSS 'font' property instead of the HTML
          FONT element to control font styles.
          Techniques for checkpoint 3.3
          
   3.4 Use relative rather than absolute units in markup language
          attribute values and style sheet property values. [Priority 2]
          For example, in CSS, use 'em' or percentage lengths rather than
          'pt' or 'cm', which are absolute units. If absolute units are
          used, validate that the rendered content is usable (refer to
          the section on validation).
          Techniques for checkpoint 3.4
          
   3.5 Use header elements to convey document structure and use them
          according to specification. [Priority 2]
          For example, in HTML, use H2 to indicate a subsection of H1. Do
          not use headers for font effects.
          Techniques for checkpoint 3.5
          
   3.6 Mark up lists and list items properly. [Priority 2]
          For example, in HTML, nest OL, UL, and DL lists properly.
          Techniques for checkpoint 3.6
          
   3.7 Mark up quotations. Do not use quotation markup for formatting
          effects such as indentation. [Priority 2]
          For example, in HTML, use the Q and BLOCKQUOTE elements to
          markup short and longer quotations, respectively.
          Techniques for checkpoint 3.7
          
  Guideline 4. Clarify natural language usage
  
   Next guideline: 5 Previous guideline: 3 Go to contents 
   
    Use markup that facilitates pronunciation or interpretation of abbreviated
    or foreign text.
    
   When content developers mark up natural language changes in a
   document, speech synthesizers and braille devices can automatically
   switch to the new language, making the document more accessible to
   multilingual users. Content developers should identify the predominant
   natural language of a document's content (through markup or HTTP
   headers). Content developers should also provide expansions of
   abbreviations and acronyms.
   
   In addition to helping assistive technologies, natural language markup
   allows search engines to find key words and identify documents in a
   desired language. Natural language markup also improves readability of
   the Web for all people, including those with learning disabilities,
   cognitive disabilities, or people who are deaf.
   
   When abbreviations and natural language changes are not identified,
   they may be indecipherable when machine-spoken or brailled.
   
    Checkpoints:
    
   4.1 Clearly identify changes in the natural language of a document's
          text and any text equivalents (e.g., captions). [Priority 1]
          For example, in HTML use the "lang" attribute. In XML, use
          "xml:lang".
          Techniques for checkpoint 4.1
          
   4.2 Specify the expansion of each abbreviation or acronym in a
          document where it first occurs. [Priority 3]
          For example, in HTML, use the "title" attribute of the ABBR and
          ACRONYM elements. Providing the expansion in the main body of
          the document also helps document usability.
          Techniques for checkpoint 4.2
          
   4.3 Identify the primary natural language of a document. [Priority 3]
          For example, in HTML set the "lang" attribute on the HTML
          element. In XML, use "xml:lang". Server operators should
          configure servers to take advantage of HTTP content negotiation
          mechanisms ([RFC2068], section 14.13) so that clients can
          automatically retrieve documents of the preferred language.
          Techniques for checkpoint 4.3
          
  Guideline 5. Create tables that transform gracefully.
  
   Next guideline: 6 Previous guideline: 4 Go to contents 
   
    Ensure that tables have necessary markup to be transformed by accessible
    browsers and other user agents.
    
   Tables should be used to mark up truly tabular information ("data
   tables"). Content developers should avoid using them to lay out pages
   ("layout tables"). Tables for any use also present special problems to
   users of screen readers (refer to checkpoint 10.3).
   
   Some user agents allow users to navigate among table cells and access
   header and other table cell information. Unless marked-up properly,
   these tables will not provide user agents with the appropriate
   information. (Refer also to guideline 3.)
   
   The following checkpoints will directly benefit people who access a
   table through auditory means (e.g., a screen reader or an
   automobile-based personal computer) or who view only a portion of the
   page at a time (e.g., users with blindness or low vision using speech
   output or a braille display, or other users of devices with small
   displays, etc.).
   
    Checkpoints:
    
   5.1 For data tables, identify row and column headers. [Priority 1]
          For example, in HTML, use TD to identify data cells and TH to
          identify headers.
          Techniques for checkpoint 5.1
          
   5.2 For data tables that have two or more logical levels of row or
          column headers, use markup to associate data cells and header
          cells. [Priority 1]
          For example, in HTML, use THEAD, TFOOT, and TBODY to group
          rows, COL and COLGROUP to group columns, and the "axis",
          "scope", and "headers" attributes, to describe more complex
          relationships among data.
          Techniques for checkpoint 5.2
          
   5.3 Do not use tables for layout unless the table makes sense when
          linearized. Otherwise, if the table does not make sense,
          provide an alternative equivalent (which may be a linearized
          version). [Priority 2]
          Note. Once user agents support style sheet positioning, tables
          should not be used for layout. Refer also to checkpoint 3.3.
          Techniques for checkpoint 5.3
          
   5.4 If a table is used for layout, do not use any structural markup
          for the purpose of visual formatting. [Priority 2]
          For example, in HTML do not use the TH element to cause the
          content of a (non-table header) cell to be displayed centered
          and in bold.
          Techniques for checkpoint 5.4
          
   5.5 Provide summaries for tables. [Priority 3]
          For example, in HTML, use the "summary" attribute of the TABLE
          element.
          Techniques for checkpoint 5.5
          
   5.6 Provide abbreviations for header labels. [Priority 3]
          For example, in HTML, use the "abbr" attribute on the TH
          element.
          Techniques for checkpoint 5.6
          
   Refer also to checkpoint 10.3.
   
  Guideline 6. Ensure that pages featuring new technologies transform
  gracefully.
  
   Next guideline: 7 Previous guideline: 5 Go to contents 
   
    Ensure that pages are accessible even when newer technologies are not
    supported or are turned off.
    
   Although content developers are encouraged to use new technologies
   that solve problems raised by existing technologies, they should know
   how to make their pages still work with older browsers and people who
   choose to turn off features.
   
    Checkpoints:
    
   6.1 Organize documents so they may be read without style sheets. For
          example, when an HTML document is rendered without associated
          style sheets, it must still be possible to read the document.
          [Priority 1]
          When content is organized logically, it will be rendered in a
          meaningful order when style sheets are turned off or not
          supported.
          Techniques for checkpoint 6.1
          
   6.2 Ensure that equivalents for dynamic content are updated when the
          dynamic content changes. [Priority 1]
          Techniques for checkpoint 6.2
          
   6.3 Ensure that pages are usable when scripts, applets, or other
          programmatic objects are turned off or not supported. If this
          is not possible, provide equivalent information on an
          alternative accessible page. [Priority 1]
          For example, ensure that links that trigger scripts work when
          scripts are turned off or not supported (e.g., do not use
          "javascript:" as the link target). If it is not possible to
          make the page usable without scripts, provide a text equivalent
          with the NOSCRIPT element, or use a server-side script instead
          of a client-side script, or provide an alternative accessible
          page as per checkpoint 11.4. Refer also to guideline 1.
          Techniques for checkpoint 6.3
          
   6.4 For scripts and applets, ensure that event handlers are input
          device-independent. [Priority 2]
          Refer to the definition of device independence.
          Techniques for checkpoint 6.4
          
   6.5 Ensure that dynamic content is accessible or provide an
          alternative presentation or page. [Priority 2]
          For example, in HTML, use NOFRAMES at the end of each frameset.
          For some applications, server-side scripts may be more
          accessible than client-side scripts.
          Techniques for checkpoint 6.5
          
   Refer also to checkpoint 11.4.
   
  Guideline 7. Ensure user control of time-sensitive content changes.
  
   Next guideline: 8 Previous guideline: 6 Go to contents 
   
    Ensure that moving, blinking, scrolling, or auto-updating objects or pages
    may be paused or stopped.
    
   Some people with cognitive or visual disabilities are unable to read
   moving text quickly enough or at all. Movement can also cause such a
   distraction that the rest of the page becomes unreadable for people
   with cognitive disabilities. Screen readers are unable to read moving
   text. People with physical disabilities might not be able to move
   quickly or accurately enough to interact with moving objects.
   
   Note. All of the following checkpoints involve some content developer
   responsibility until user agents provide adequate feature control
   mechanisms.
   
    Checkpoints:
    
   7.1 Until user agents allow users to control flickering, avoid causing
          the screen to flicker. [Priority 1]
          Note. People with photosensitive epilepsy can have seizures
          triggered by flickering or flashing in the 4 to 59 flashes per
          second (Hertz) range with a peak sensitivity at 20 flashes per
          second as well as quick changes from dark to light (like strobe
          lights).
          Techniques for checkpoint 7.1
          
   7.2 Until user agents allow users to control blinking, avoid causing
          content to blink (i.e., change presentation at a regular rate,
          such as turning on and off). [Priority 2]
          Techniques for checkpoint 7.2
          
   7.3 Until user agents allow users to freeze moving content, avoid
          movement in pages. [Priority 2]
          When a page includes moving content, provide a mechanism within
          a script or applet to allow users to freeze motion or updates.
          Using style sheets with scripting to create movement allows
          users to turn off or override the effect more easily. Refer
          also to guideline 8.
          Techniques for checkpoint 7.3
          
   7.4 Until user agents provide the ability to stop the refresh, do not
          create periodically auto-refreshing pages. [Priority 2]
          For example, in HTML, don't cause pages to auto-refresh with
          "HTTP-EQUIV=refresh" until user agents allow users to turn off
          the feature.
          Techniques for checkpoint 7.4
          
   7.5 Until user agents provide the ability to stop auto-redirect, do
          not use markup to redirect pages automatically. Instead,
          configure the server to perform redirects. [Priority 2]
          Techniques for checkpoint 7.5
          
   Note. The BLINK and MARQUEE elements are not defined in any W3C HTML
   specification and should not be used. Refer also to guideline 11.
   
  Guideline 8. Ensure direct accessibility of embedded user interfaces.
  
   Next guideline: 9 Previous guideline: 7 Go to contents 
   
    Ensure that the user interface follows principles of accessible design:
    device-independent access to functionality, keyboard operability,
    self-voicing, etc.
    
   When an embedded object has its "own interface", the interface -- like
   the interface to the browser itself -- must be accessible. If the
   interface of the embedded object cannot be made accessible, an
   alternative accessible solution must be provided.
   
   Note. For information about accessible interfaces, please consult the
   User Agent Accessibility Guidelines ([WAI-USERAGENT]) and the
   Authoring Tool Accessibility Guidelines ([WAI-AUTOOL]).
   
    Checkpoint:
    
   8.1 Make programmatic elements such as scripts and applets directly
          accessible or compatible with assistive technologies
          [Priority 1 if functionality is important and not presented
          elsewhere, otherwise Priority 2.]
          Refer also to guideline 6.
          Techniques for checkpoint 8.1
          
  Guideline 9. Design for device-independence.
  
   Next guideline: 10 Previous guideline: 8 Go to contents 
   
    Use features that enable activation of page elements via a variety of input
    devices.
    
   Device-independent access means that the user may interact with the
   user agent or document with a preferred input (or output) device --
   mouse, keyboard, voice, head wand, or other. If, for example, a form
   control can only be activated with a mouse or other pointing device,
   someone who is using the page without sight, with voice input, or with
   a keyboard or who is using some other non-pointing input device will
   not be able to use the form.
   
   Note. Providing text equivalents for image maps or images used as
   links makes it possible for users to interact with them without a
   pointing device. Refer also to guideline 1.
   
   Generally, pages that allow keyboard interaction are also accessible
   through speech input or a command line interface.
   
    Checkpoints:
    
   9.1 Provide client-side image maps instead of server-side image maps
          except where the regions cannot be defined with an available
          geometric shape. [Priority 1]
          Refer also to checkpoint 1.1, checkpoint 1.2, and checkpoint
          1.5.
          Techniques for checkpoint 9.1
          
   9.2 Ensure that any element that has its own interface can be operated
          in a device-independent manner. [Priority 2]
          Refer to the definition of device independence.
          Refer also to guideline 8.
          Techniques for checkpoint 9.2
          
   9.3 For scripts, specify logical event handlers rather than
          device-dependent event handlers. [Priority 2]
          Techniques for checkpoint 9.3
          
   9.4 Create a logical tab order through links, form controls, and
          objects. [Priority 3]
          For example, in HTML, specify tab order via the "tabindex"
          attribute or ensure a logical page design.
          Techniques for checkpoint 9.4
          
   9.5 Provide keyboard shortcuts to important links (including those in
          client-side image maps), form controls, and groups of form
          controls. [Priority 3]
          For example, in HTML, specify shortcuts via the "accesskey"
          attribute.
          Techniques for checkpoint 9.5
          
  Guideline 10. Use interim solutions.
  
   Next guideline: 11 Previous guideline: 9 Go to contents 
   
    Use interim accessibility solutions so that assistive technologies and
    older browsers will operate correctly.
    
   For example, older browsers do not allow users to navigate to empty
   edit boxes. Older screen readers read lists of consecutive links as
   one link. These active elements are therefore difficult or impossible
   to access. Also, changing the current window or popping up new windows
   can be very disorienting to users who cannot see that this has
   happened.
   
   Note. The following checkpoints apply until user agents (including
   assistive technologies) address these issues. These checkpoints are
   classified as "interim", meaning that the Web Content Guidelines
   Working Group considers them to be valid and necessary to Web
   accessibility as of the publication of this document. However, the
   Working Group does not expect these checkpoints to be necessary in the
   future, once Web technologies have incorporated anticipated features
   or capabilities.
   
    Checkpoints:
    
   10.1 Until user agents allow users to turn off spawned windows, do not
          cause pop-ups or other windows to appear and do not change the
          current window without informing the user. [Priority 2]
          For example, in HTML, avoid using a frame whose target is a new
          window.
          Techniques for checkpoint 10.1
          
   10.2 Until user agents support explicit associations between labels
          and form controls, for all form controls with implicitly
          associated labels, ensure that the label is properly
          positioned. [Priority 2]
          The label must immediately precede its control on the same line
          (allowing more than one control/label per line) or be in the
          line preceding the control (with only one label and one control
          per line). Refer also to checkpoint 12.4.
          Techniques for checkpoint 10.2
          
   10.3 Until user agents (including assistive technologies) render
          side-by-side text correctly, provide a linear text alternative
          (on the current page or some other) for all tables that lay out
          text in parallel, word-wrapped columns. [Priority 3]
          Note. Please consult the definition of linearized table. This
          checkpoint benefits people with user agents (such as some
          screen readers) that are unable to handle blocks of text
          presented side-by-side; the checkpoint should not discourage
          content developers from using tables to represent tabular
          information.
          Techniques for checkpoint 10.3
          
   10.4 Until user agents handle empty controls correctly, include
          default, place-holding characters in edit boxes and text areas.
          [Priority 3]
          For example, in HTML, do this for TEXTAREA and INPUT.
          Techniques for checkpoint 10.4
          
   10.5 Until user agents (including assistive technologies) render
          adjacent links distinctly, include non-link, printable
          characters (surrounded by spaces) between adjacent links.
          [Priority 3]
          Techniques for checkpoint 10.5
          
  Guideline 11. Use W3C technologies and guidelines.
  
   Next guideline: 12 Previous guideline: 10 Go to contents 
   
    Use W3C technologies (according to specification) and follow accessibility
    guidelines. Where it is not possible to use a W3C technology, or doing so
    results in material that does not transform gracefully, provide an
    alternative version of the content that is accessible.
    
   The current guidelines recommend W3C technologies (e.g., HTML, CSS,
   etc.) for several reasons:
     * W3C technologies include "built-in" accessibility features.
     * W3C specifications undergo early review to ensure that
       accessibility issues are considered during the design phase.
     * W3C specifications are developed in an open, industry consensus
       process.
       
   Many non-W3C formats (e.g., PDF, Shockwave, etc.) require viewing with
   either plug-ins or stand-alone applications. Often, these formats
   cannot be viewed or navigated with standard user agents (including
   assistive technologies). Avoiding non-W3C and non-standard features
   (proprietary elements, attributes, properties, and extensions) will
   tend to make pages more accessible to more people using a wider
   variety of hardware and software. When inaccessible technologies
   (proprietary or not) must be used, equivalent accessible pages must be
   provided.
   
   Even when W3C technologies are used, they must be used in accordance
   with accessibility guidelines. When using new technologies, ensure
   that they transform gracefully (Refer also to guideline 6.).
   
   Note. Converting documents (from PDF, PostScript, RTF, etc.) to W3C
   markup languages (HTML, XML) does not always create an accessible
   document. Therefore, validate each page for accessibility and
   usability after the conversion process (refer to the section on
   validation). If a page does not readily convert, either revise the
   page until its original representation converts appropriately or
   provide an HTML or plain text version.
   
    Checkpoints:
    
   11.1 Use W3C technologies when they are available and appropriate for
          a task and use the latest versions when supported. [Priority 2]
          Refer to the list of references for information about where to
          find the latest W3C specifications and [WAI-UA-SUPPORT] for
          information about user agent support for W3C technologies.
          Techniques for checkpoint 11.1
          
   11.2 Avoid deprecated features of W3C technologies. [Priority 2]
          For example, in HTML, don't use the deprecated FONT element;
          use style sheets instead (e.g., the 'font' property in CSS).
          Techniques for checkpoint 11.2
          
   11.3 Provide information so that users may receive documents according
          to their preferences (e.g., language, content type, etc.)
          [Priority 3]
          Note. Use content negotiation where possible.
          Techniques for checkpoint 11.3
          
   11.4 If, after best efforts, you cannot create an accessible page,
          provide a link to an alternative page that uses W3C
          technologies, is accessible, has equivalent information (or
          functionality), and is updated as often as the inaccessible
          (original) page. [Priority 1]
          Techniques for checkpoint 11.4
          
   Note. Content developers should only resort to alternative pages when
   other solutions fail because alternative pages are generally updated
   less often than "primary" pages. An out-of-date page may be as
   frustrating as one that is inaccessible since, in both cases, the
   information presented on the original page is unavailable.
   Automatically generating alternative pages may lead to more frequent
   updates, but content developers must still be careful to ensure that
   generated pages always make sense, and that users are able to navigate
   a site by following links on primary pages, alternative pages, or
   both. Before resorting to an alternative page, reconsider the design
   of the original page; making it accessible is likely to improve it for
   all users.
   
  Guideline 12. Provide context and orientation information.
  
   Next guideline: 13 Previous guideline: 11 Go to contents 
   
    Provide context and orientation information to help users understand
    complex pages or elements.
    
   Grouping elements and providing contextual information about the
   relationships between elements can be useful for all users. Complex
   relationships between parts of a page may be difficult for people with
   cognitive disabilities and people with visual disabilities to
   interpret.
   
    Checkpoints:
    
   12.1 Title each frame to facilitate frame identification and
          navigation. [Priority 1]
          For example, in HTML use the "title" attribute on FRAME
          elements.
          Techniques for checkpoint 12.1
          
   12.2 Describe the purpose of frames and how frames relate to each
          other if it is not obvious by frame titles alone. [Priority 2]
          For example, in HTML, use "longdesc," or a description link.
          Techniques for checkpoint 12.2
          
   12.3 Divide large blocks of information into more manageable groups
          where natural and appropriate. [Priority 2]
          For example, in HTML, use OPTGROUP to group OPTION elements
          inside a SELECT; group form controls with FIELDSET and LEGEND;
          use nested lists where appropriate; use headings to structure
          documents, etc. Refer also to guideline 3.
          Techniques for checkpoint 12.3
          
   12.4 Associate labels explicitly with their controls. [Priority 2]
          For example, in HTML use LABEL and its "for" attribute.
          Techniques for checkpoint 12.4
          
  Guideline 13. Provide clear navigation mechanisms.
  
   Next guideline: 14 Previous guideline: 12 Go to contents 
   
    Provide clear and consistent navigation mechanisms -- orientation
    information, navigation bars, a site map, etc. -- to increase the
    likelihood that a person will find what they are looking for at a site.
    
   Clear and consistent navigation mechanisms are important to people
   with cognitive disabilities or blindness, and benefit all users.
   
    Checkpoints:
    
   13.1 Clearly identify the target of each link. [Priority 2]
          Link text should be meaningful enough to make sense when read
          out of context -- either on its own or as part of a sequence of
          links. Link text should also be terse.
          For example, in HTML, write "Information about version 4.3"
          instead of "click here". In addition to clear link text,
          content developers may further clarify the target of a link
          with an informative link title (e.g., in HTML, the "title"
          attribute).
          Techniques for checkpoint 13.1
          
   13.2 Provide metadata to add semantic information to pages and sites.
          [Priority 2]
          For example, use RDF ([RDF]) to indicate the document's author,
          the type of content, etc.
          Note. Some HTML user agents can build navigation tools from
          document relations described by the HTML LINK element and "rel"
          or "rev" attributes (e.g., rel="next", rel="previous",
          rel="index", etc.). Refer also to checkpoint 13.5.
          Techniques for checkpoint 13.2
          
   13.3 Provide information about the general layout of a site (e.g., a
          site map or table of contents). [Priority 2]
          In describing site layout, highlight and explain available
          accessibility features.
          Techniques for checkpoint 13.3
          
   13.4 Use navigation mechanisms in a consistent manner. [Priority 2]
          Techniques for checkpoint 13.4
          
   13.5 Provide navigation bars to highlight and give access to the
          navigation mechanism. [Priority 3]
          Techniques for checkpoint 13.5
          
   13.6 Group related links, identify the group (for user agents), and,
          until user agents do so, provide a way to bypass the group.
          [Priority 3]
          Techniques for checkpoint 13.6
          
   13.7 If search functions are provided, enable different types of
          searches for different skill levels and preferences.
          [Priority 3]
          Techniques for checkpoint 13.7
          
   13.8 Place distinguishing information at the beginning of headings,
          paragraphs, lists, etc. [Priority 3]
          Note. This is commonly referred to as "front-loading" and is
          especially helpful for people accessing information with serial
          devices such as speech synthesizers.
          Techniques for checkpoint 13.8
          
   13.9 Provide information about document collections (i.e., documents
          comprising multiple pages.). [Priority 3]
          For example, in HTML specify document collections with the LINK
          element and the "rel" and "rev" attributes. Another way to
          create a collection is by building an archive (e.g., with zip,
          tar and gzip, stuffit, etc.) of the multiple pages.
          Note. The performance improvement gained by offline processing
          can make browsing much less expensive for people with
          disabilities who may be browsing slowly.
          Techniques for checkpoint 13.9
          
   13.10 Provide a means to skip over multi-line ASCII art. [Priority 3]
          Refer to checkpoint 1.1 and the example of ascii art in the
          glossary.
          Techniques for checkpoint 13.10
          
  Guideline 14. Ensure that documents are clear and simple.
  
   Next guideline: 1 Previous guideline: 13 Go to contents 
   
    Ensure that documents are clear and simple so they may be more easily
    understood.
    
   Consistent page layout, recognizable graphics, and easy to understand
   language benefit all users. In particular, they help people with
   cognitive disabilities or who have difficulty reading. (However,
   ensure that images have text equivalents for people who are blind,
   have low vision, or for any user who cannot or has chosen not to view
   graphics. Refer also to guideline 1.)
   
   Using clear and simple language promotes effective communication.
   Access to written information can be difficult for people who have
   cognitive or learning disabilities. Using clear and simple language
   also benefits people whose first language differs from your own,
   including those people who communicate primarily in sign language.
   
    Checkpoints:
    
   14.1 Use the clearest and simplest language appropriate for a site's
          content. [Priority 1]
          Techniques for checkpoint 14.1
          
   14.2 Supplement text with graphic or auditory presentations where they
          will facilitate comprehension of the page. [Priority 3]
          Refer also to guideline 1.
          Techniques for checkpoint 14.2
          
   14.3 Create a style of presentation that is consistent across pages.
          [Priority 3]
          Techniques for checkpoint 14.3
     _________________________________________________________________
   
Appendix A. -- Validation

   Validate accessibility with automatic tools and human review.
   Automated methods are generally rapid and convenient but cannot
   identify all accessibility issues. Human review can help ensure
   clarity of language and ease of navigation.
   
   Begin using validation methods at the earliest stages of development.
   Accessibility issues identified early are easier to correct and avoid.
   
   Following are some important validation methods, discussed in more
   detail in the section on validation in the Techniques Document.
    1. Use an automated accessibility tool and browser validation tool.
       Please note that software tools do not address all accessibility
       issues, such as the meaningfulness of link text, the applicability
       of a text equivalent, etc.
    2. Validate syntax (e.g., HTML, XML, etc.).
    3. Validate style sheets (e.g., CSS).
    4. Use a text-only browser or emulator.
    5. Use multiple graphic browsers, with:
          + sounds and graphics loaded,
          + graphics not loaded,
          + sounds not loaded,
          + no mouse,
          + frames, scripts, style sheets, and applets not loaded
    6. Use several browsers, old and new.
    7. Use a self-voicing browser, a screen reader, magnification
       software, a small display, etc.
    8. Use spell and grammar checkers. A person reading a page with a
       speech synthesizer may not be able to decipher the synthesizer's
       best guess for a word with a spelling error. Eliminating grammar
       problems increases comprehension.
    9. Review the document for clarity and simplicity. Readability
       statistics, such as those generated by some word processors may be
       useful indicators of clarity and simplicity. Better still, ask an
       experienced (human) editor to review written content for clarity.
       Editors can also improve the usability of documents by identifying
       potentially sensitive cultural issues that might arise due to
       language or icon usage.
   10. Invite people with disabilities to review documents. Expert and
       novice users with disabilities will provide valuable feedback
       about accessibility or usability problems and their severity.
     _________________________________________________________________
   
Appendix B. -- Glossary

   Accessible
          Content is accessible when it may be used by someone with a
          disability.
          
   Applet
          A program inserted into a Web page.
          
   Assistive technology
          Software or hardware that has been specifically designed to
          assist people with disabilities in carrying out daily
          activities. Assistive technology includes wheelchairs, reading
          machines, devices for grasping, etc. In the area of Web
          Accessibility, common software-based assistive technologies
          include screen readers, screen magnifiers, speech synthesizers,
          and voice input software that operate in conjunction with
          graphical desktop browsers (among other user agents). Hardware
          assistive technologies include alternative keyboards and
          pointing devices.
          
   ASCII art
          ASCII art refers to text characters and symbols that are
          combined to create an image. For example ";-)" is the smiley
          emoticon. The following is an ascii figure showing the
          relationship between flash frequency and photoconvulsive
          response in patients with eyes open and closed [skip over ascii
          figure or consult a description of chart]:
          

  %   __ __ __ __ __ __ __ __ __ __ __ __ __ __
100 |             *                             |
 90 |                *  *                       |
 80 |          *           *                    |
 70 |             @           *                 |
 60 |          @                 *              |
 50 |       *        @              *           |
 40 |                   @              *        |
 30 |    *  @              @  @           *     |
 20 |                                           |
 10 |    @                       @  @  @  @     |
      0  5 10 15 20 25 30 35 40 45 50 55 60 65 70
      Flash frequency (Hertz)

   Authoring tool
          HTML editors, document conversion tools, tools that generate
          Web content from databases are all authoring tools. Refer to
          the "Authoring Tool Accessibility Guidelines" ([WAI-AUTOOLS])
          for information about developing accessible tools.
          
   Backward compatible
          Design that continues to work with earlier versions of a
          language, program, etc.
          
   Braille
          Braille uses six raised dots in different patterns to represent
          letters and numbers to be read by people who are blind with
          their fingertips. The word "Accessible" in braille follows:
          Accessible
          A braille display, commonly referred to as a "dynamic braille
          display," raises or lowers dot patterns on command from an
          electronic device, usually a computer. The result is a line of
          braille that can change from moment to moment. Current dynamic
          braille displays range in size from one cell (six or eight
          dots) to an eighty-cell line, most having between twelve and
          twenty cells per line.
          
   Content developer
          Someone who authors Web pages or designs Web sites.
          
   Deprecated 
          A deprecated element or attribute is one that has been outdated
          by newer constructs. Deprecated elements may become obsolete in
          future versions of HTML. The index of HTML elements and
          attributes in the Techniques Document indicates which elements
          and attributes are deprecated in HTML 4.0.
          Authors should avoid using deprecated elements and attributes.
          User agents should continue to support for reasons of backward
          compatibility.
          
   Device independent
          Users must be able to interact with a user agent (and the
          document it renders) using the supported input and output
          devices of their choice and according to their needs. Input
          devices may include pointing devices, keyboards, braille
          devices, head wands, microphones, and others. Output devices
          may include monitors, speech synthesizers, and braille devices.
          Please note that "device-independent support" does not mean
          that user agents must support every input or output device.
          User agents should offer redundant input and output mechanisms
          for those devices that are supported. For example, if a user
          agent supports keyboard and mouse input, users should be able
          to interact with all features using either the keyboard or the
          mouse.
          
   Document Content, Structure, and Presentation
          The content of a document refers to what it says to the user
          through natural language, images, sounds, movies, animations,
          etc. The structure of a document is how it is organized
          logically (e.g., by chapter, with an introduction and table of
          contents, etc.). An element (e.g., P, STRONG, BLOCKQUOTE in
          HTML) that specifies document structure is called a structural
          element. The presentation of a document is how the document is
          rendered (e.g., as print, as a two-dimensional graphical
          presentation, as an text-only presentation, as synthesized
          speech, as braille, etc.) An element that specifies document
          presentation (e.g., B, FONT, CENTER) is called a presentation
          element.
          Consider a document header, for example. The content of the
          header is what the header says (e.g., "Sailboats"). In HTML,
          the header is a structural element marked up with, for example,
          an H2 element. Finally, the presentation of the header might be
          a bold block text in the margin, a centered line of text, a
          title spoken with a certain voice style (like an aural font),
          etc.
          
   Dynamic HTML (DHTML)
          DHTML is the marketing term applied to a mixture of standards
          including HTML, style sheets, the Document Object Model [DOM1]
          and scripting. However, there is no W3C specification that
          formally defines DHTML. Most guidelines may be applicable to
          applications using DHTML, however the following guidelines
          focus on issues related to scripting and style sheets:
          guideline 1, guideline 3, guideline 6, guideline 7, and
          guideline 9.
          
   Element
          This document uses the term "element" both in the strict SGML
          sense (an element is a syntactic construct) and more generally
          to mean a type of content (such as video or sound) or a logical
          construct (such as a header or list). The second sense
          emphasizes that a guideline inspired by HTML could easily apply
          to another markup language.
          Note that some (SGML) elements have content that is rendered
          (e.g., the P, LI, or TABLE elements in HTML), some are replaced
          by external content (e.g., IMG), and some affect processing
          (e.g., STYLE and SCRIPT cause information to be processed by a
          style sheet or script engine). An element that causes text
          characters to be part of the document is called a text element.
          
   Equivalent
          Content is "equivalent" to other content when both fulfill
          essentially the same function or purpose upon presentation to
          the user. In the context of this document, the equivalent must
          fulfill essentially the same function for the person with a
          disability (at least insofar as is feasible, given the nature
          of the disability and the state of technology), as the primary
          content does for the person without any disability. For
          example, the text "The Full Moon" might convey the same
          information as an image of a full moon when presented to users.
          Note that equivalent information focuses on fulfilling the same
          function. If the image is part of a link and understanding the
          image is crucial to guessing the link target, an equivalent
          must also give users an idea of the link target. Providing
          equivalent information for inaccessible content is one of the
          primary ways authors can make their documents accessible to
          people with disabilities.
          As part of fulfilling the same function of content an
          equivalent may involve a description of that content (i.e.,
          what the content looks like or sounds like). For example, in
          order for users to understand the information conveyed by a
          complex chart, authors should describe the visual information
          in the chart.
          Since text content can be presented to the user as synthesized
          speech, braille, and visually-displayed text, these guidelines
          require text equivalents for graphic and audio information.
          Text equivalents must be written so that they convey all
          essential content. Non-text equivalents (e.g., an auditory
          description of a visual presentation, a video of a person
          telling a story using sign language as an equivalent for a
          written story, etc.) also improve accessibility for people who
          cannot access visual information or written text, including
          many individuals with blindness, cognitive disabilities,
          learning disabilities, and deafness.
          Equivalent information may be provided in a number of ways,
          including through attributes (e.g., a text value for the "alt"
          attribute in HTML and SMIL), as part of element content (e.g.,
          the OBJECT in HTML), as part of the document's prose, or via a
          linked document (e.g., designated by the "longdesc" attribute
          in HTML or a description link). Depending on the complexity of
          the equivalent, it may be necessary to combine techniques
          (e.g., use "alt" for an abbreviated equivalent, useful to
          familiar readers, in addition to "longdesc" for a link to more
          complete information, useful to first-time readers). The
          details of how and when to provide equivalent information are
          part of the Techniques Document ([TECHNIQUES]).
          A text transcript is a text equivalent of audio information
          that includes spoken words and non-spoken sounds such as sound
          effects. A caption is a text transcript for the audio track of
          a video presentation that is synchronized with the video and
          audio tracks. Captions are generally rendered visually by being
          superimposed over the video, which benefits people who are deaf
          and hard-of-hearing, and anyone who cannot hear the audio
          (e.g., when in a crowded room). A collated text transcript
          combines (collates) captions with text descriptions of video
          information (descriptions of the actions, body language,
          graphics, and scene changes of the video track). These text
          equivalents make presentations accessible to people who are
          deaf-blind and to people who cannot play movies, animations,
          etc. It also makes the information available to search engines.
          One example of a non-text equivalent is an auditory description
          of the key visual elements of a presentation. The description
          is either a prerecorded human voice or a synthesized voice
          (recorded or generated on the fly). The auditory description is
          synchronized with the audio track of the presentation, usually
          during natural pauses in the audio track. Auditory descriptions
          include information about actions, body language, graphics, and
          scene changes.
          
   Image
          A graphical presentation.
          
   Image map
          An image that has been divided into regions with associated
          actions. Clicking on an active region causes an action to
          occur.
          When a user clicks on an active region of a client-side image
          map, the user agent calculates in which region the click
          occurred and follows the link associated with that region.
          Clicking on an active region of a server-side image map causes
          the coordinates of the click to be sent to a server, which then
          performs some action.
          Content developers can make client-side image maps accessible
          by providing device-independent access to the same links
          associated with the image map's regions. Client-side image maps
          allow the user agent to provide immediate feedback as to
          whether or not the user's pointer is over an active region.
          
   Important
          Information in a document is important if understanding that
          information is crucial to understanding the document.
          
   Linearized table
          A table rendering process where the contents of the cells
          become a series of paragraphs (e.g., down the page) one after
          another. The paragraphs will occur in the same order as the
          cells are defined in the document source. Cells should make
          sense when read in order and should include structural elements
          (that create paragraphs, headers, lists, etc.) so the page
          makes sense after linearization.
          
   Link text
          The rendered text content of a link.
          
   Natural Language
          Spoken, written, or signed human languages such as French,
          Japanese, American Sign Language, and braille. The natural
          language of content may be indicated with the "lang" attribute
          in HTML ([HTML40], section 8.1) and the "xml:lang" attribute in
          XML ([XML], section 2.12).
          
   Navigation Mechanism
          A navigation mechanism is any means by which a user can
          navigate a page or site. Some typical mechanisms include:
          
        navigation bars
                A navigation bar is a collection of links to the most
                important parts of a document or site.
                
        site maps
                A site map provides a global view of the organization of
                a page or site.
                
        tables of contents
                A table of contents generally lists (and links to) the
                most important sections of a document.
                
   Personal Digital Assistant (PDA)
          A PDA is a small, portable computing device. Most PDAs are used
          to track personal data such as calendars, contacts, and
          electronic mail. A PDA is generally a handheld device with a
          small screen that allows input from various sources.
          
   Screen magnifier
          A software program that magnifies a portion of the screen, so
          that it can be more easily viewed. Screen magnifiers are used
          primarily by individuals with low vision.
          
   Screen reader
          A software program that reads the contents of the screen aloud
          to a user. Screen readers are used primarily by individuals who
          are blind. Screen readers can usually only read text that is
          printed, not painted, to the screen.
          
   Style sheets
          A style sheet is a set of statements that specify presentation
          of a document. Style sheets may have three different origins:
          they may be written by content providers, created by users, or
          built into user agents. In CSS ([CSS2]), the interaction of
          content provider, user, and user agent style sheets is called
          the cascade.
          Presentation markup is markup that achieves a stylistic (rather
          than structuring) effect such as the B or I elements in HTML.
          Note that the STRONG and EM elements are not considered
          presentation markup since they convey information that is
          independent of a particular font style.
          
   Tabular information
          When tables are used to represent logical relationships among
          data -- text, numbers, images, etc., that information is called
          "tabular information" and the tables are called "data tables".
          The relationships expressed by a table may be rendered visually
          (usually on a two-dimensional grid), aurally (often preceding
          cells with header information), or in other formats.
          
   Until user agents ...
          In most of the checkpoints, content developers are asked to
          ensure the accessibility of their pages and sites. However,
          there are accessibility needs that would be more appropriately
          met by user agents (including assistive technologies). As of
          the publication of this document, not all user agents or
          assistive technologies provide the accessibility control users
          require (e.g., some user agents may not allow users to turn off
          blinking content, or some screen readers may not handle tables
          well). Checkpoints that contain the phrase "until user agents
          ..." require content developers to provide additional support
          for accessibility until most user agents readily available to
          their audience include the necessary accessibility features.
          Note. The W3C WAI Web site (refer to [WAI-UA-SUPPORT]) provides
          information about user agent support for accessibility
          features. Content developers are encouraged to consult this
          page regularly for updated information.
          
   User agent
          Software to access Web content, including desktop graphical
          browsers, text browsers, voice browsers, mobile phones,
          multimedia players, plug-ins, and some software assistive
          technologies used in conjunction with browsers such as screen
          readers, screen magnifiers, and voice recognition software.
     _________________________________________________________________
   
Acknowledgments

   Web Content Guidelines Working Group Co-Chairs:
          Chuck Letourneau, Starling Access Services
          Gregg Vanderheiden, Trace Research and Development
          
   W3C Team contacts:
          Judy Brewer and Daniel Dardailler
          
   We wish to thank the following people who have contributed their time
          and valuable comments to shaping these guidelines:
          Harvey Bingham, Kevin Carey, Chetz Colwell, Neal Ewers, Geoff
          Freed, Al Gilman, Larry Goldberg, Jon Gunderson, Eric Hansen,
          Phill Jenkins, Leonard Kasday, George Kerscher, Marja-Riitta
          Koivunen, Josh Krieger, Scott Luebking, William Loughborough,
          Murray Maloney, Charles McCathieNevile, MegaZone (Livingston
          Enterprises), Masafumi Nakane, Mark Novak, Charles Oppermann,
          Mike Paciello, David Pawson, Michael Pieper, Greg Rosmaita,
          Liam Quinn, Dave Raggett, T.V. Raman, Robert Savellis, Jutta
          Treviranus, Steve Tyler, Jaap van Lelieveld, and Jason White
          
   The original draft of this document is based on "The Unified Web Site
   Accessibility Guidelines" ([UWSAG]) compiled by the Trace R & D Center
   at the University of Wisconsin. That document includes a list of
   additional contributors.
   
References

   For the latest version of any W3C specification please consult the
   list of W3C Technical Reports.
   
   [CSS1]
          "CSS, level 1 Recommendation", B. Bos, H. Wium Lie, eds., 17
          December 1996, revised 11 January 1999. The CSS1 Recommendation
          is: http://www.w3.org/TR/1999/REC-CSS1-19990111.
          The latest version of CSS1 is available at:
          http://www.w3.org/TR/REC-CSS1.
          
   [CSS2]
          "CSS, level 2 Recommendation", B. Bos, H. Wium Lie, C. Lilley,
          and I. Jacobs, eds., 12 May 1998. The CSS2 Recommendation is:
          http://www.w3.org/TR/1998/REC-CSS2-19980512.
          The latest version of CSS2 is available at:
          http://www.w3.org/TR/REC-CSS2.
          
   [DOM1]
          "Document Object Model (DOM) Level 1 Specification", V.
          Apparao, S. Byrne, M. Champion, S. Isaacs, I. Jacobs, A. Le
          Hors, G. Nicol, J. Robie, R. Sutor, C. Wilson, and L. Wood,
          eds., 1 October 1998. The DOM Level 1 Recommendation is:
          http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001.
          The latest version of DOM Level 1 is available at:
          http://www.w3.org/TR/REC-DOM-Level-1
          
   [HTML40]
          "HTML 4.0 Recommendation", D. Raggett, A. Le Hors, and I.
          Jacobs, eds., 17 December 1997, revised 24 April 1998. The HTML
          4.0 Recommendation is:
          http://www.w3.org/TR/1998/REC-html40-19980424.
          The latest version of HTML 4.0 is available at:
          http://www.w3.org/TR/REC-html40.
          
   [HTML32]
          "HTML 3.2 Recommendation", D. Raggett, ed., 14 January 1997.
          The latest version of HTML 3.2 is available at:
          http://www.w3.org/TR/REC-html32.
          
   [MATHML]
          "Mathematical Markup Language", P. Ion and R. Miner, eds., 7
          April 1998. The MathML 1.0 Recommendation is:
          http://www.w3.org/TR/1998/REC-MathML-19980407.
          The latest version of MathML 1.0 is available at:
          http://www.w3.org/TRREC-MathML.
          
   [PNG]
          "PNG (Portable Network Graphics) Specification", T. Boutell,
          ed., T. Lane, contributing ed., 1 October 1996. The latest
          version of PNG 1.0 is: http://www.w3.org/TR/REC-png.
          
   [RDF]
          "Resource Description Framework (RDF) Model and Syntax
          Specification", O. Lassila, R. Swick, eds., 22 February 1999.
          The RDF Recommendation is:
          http://www.w3.org/TR/1999/REC-rdf-syntax-19990222.
          The latest version of RDF 1.0 is available at:
          http://www.w3.org/TR/REC-rdf-syntax
          
   [RFC2068]
          "HTTP Version 1.1", R. Fielding, J. Gettys, J. Mogul, H.
          Frystyk Nielsen, and T. Berners-Lee, January 1997.
          
   [SMIL]
          "Synchronized Multimedia Integration Language (SMIL) 1.0
          Specification", P. Hoschka, ed., 15 June 1998. The SMIL 1.0
          Recommendation is: http://www.w3.org/TR/1998/REC-smil-19980615
          The latest version of SMIL 1.0 is available at:
          http://www.w3.org/TR/REC-smil
          
   [TECHNIQUES]
          "Techniques for Web Content Accessibility Guidelines 1.0", W.
          Chisholm, G. Vanderheiden, I. Jacobs, eds. This document
          explains how to implement the checkpoints defined in "Web
          Content Accessibility Guidelines 1.0". The latest draft of the
          techniques is available at:
          http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/
          
   [WAI-AUTOOLS]
          "Authoring Tool Accessibility Guidelines", J. Treviranus, J.
          Richards, I. Jacobs, C. McCathieNevile, eds. The latest Working
          Draft of these guidelines for designing accessible authoring
          tools is available at: http://www.w3.org/TR/WAI-AUTOOLS/
          
   [WAI-UA-SUPPORT]
          This page documents known support by user agents (including
          assistive technologies) of some accessibility features listed
          in this document. The page is available at:
          http://www.w3.org/WAI/Resources/WAI-UA-Support
          
   [WAI-USERAGENT]
          "User Agent Accessibility Guidelines", J. Gunderson and I.
          Jacobs, eds. The latest Working Draft of these guidelines for
          designing accessible user agents is available at:
          http://www.w3.org/TR/WAI-USERAGENT/
          
   [WCAG-ICONS]
          Information about conformance icons for this document and how
          to use them is available at
          http://www.w3.org/WAI/WCAG1-Conformance.html
          
   [UWSAG]
          "The Unified Web Site Accessibility Guidelines", G.
          Vanderheiden, W. Chisholm, eds. The Unified Web Site Guidelines
          were compiled by the Trace R & D Center at the University of
          Wisconsin under funding from the National Institute on
          Disability and Rehabilitation Research (NIDRR),  U.S. Dept. of
          Education. This document is available at:
          http://www.tracecenter.org/docs/html_guidelines/version8.htm
          
   [XML]
          "Extensible Markup Language (XML) 1.0.", T. Bray, J. Paoli,
          C.M. Sperberg-McQueen, eds., 10 February 1998. The XML 1.0
          Recommendation is: http://www.w3.org/TR/1998/REC-xml-19980210.
          The latest version of XML 1.0 is available at:
          http://www.w3.org/TR/REC-xml
          
   Level Triple-A conformance icon, W3C-WAI Web Content Accessibility
   Guidelines 1.0 
     _________________________________________________________________
   
   [contents]   [checklist]