W3C   WD-WAI-UA-BROWSER-19980603

WAI Accessibility Guidelines:
Browser User Interface

W3C Working Draft     03-June-1998

This version:
http://www.w3.org/WAI/UA/WD-WAI-UA-BROWSER-19980603
Latest version:
http://www.w3.org/WAI/UA/WD-WAI-UA-BROWSER
Previous version:
http://www.w3.org/WAI/UA/WD-WAI-UA-BROWSER-19980602.html
Editors:
Jon Gunderson, University of Illinois at Urbana/Champaign <jongund@uiuc.edu>
Ian Jacobs <ij@w3.org>

Please see the Acknowledgments for a complete list of contributors.

Abstract

This document provides guidelines to browser designers (and to user agent designers in general) designers on how to make their products more accessible to persons with disabilities. Following the guidelines, developers will find a helpful checklist for identifying and prioritizing accessibility features.

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

Status of this document

This is [not yet] a W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". This is work in progress and does not imply endorsement by, or the consensus of, either W3C or members of the WAI User Agent (UA) working group.

This document has been produced as part of the W3C WAI Activity, and is intended as a draft of a Proposed Recommendation for how to improve browser accessibility. The goals of the WAI-UA Working Group are discussed in the WAI charter. A list of the current Working Group members is available.

Available formats

This document is available in the following formats:

HTML:
http://www.w3.org/WAI/UA/WD-WAI-UA-BROWSER-19980603
A plain text file:
http://www.w3.org/WAI/UA/WD-WAI-UA-BROWSER-19980603/wai-ua-browser.txt,
HTML as a gzip'ed tar file:
http://www.w3.org/WAI/UA/WD-WAI-UA-BROWSER-19980603/wai-ua-browser.tgz,
HTML as a zip file (this is a '.zip' file not an '.exe'):
http://www.w3.org/WAI/UA/WD-WAI-UA-BROWSER-19980603/wai-ua-browser.zip,
A gzip'ed PostScript file:
http://www.w3.org/WAI/UA/WD-WAI-UA-BROWSER-19980603/wai-ua-browser.ps.gz,
A PDF file:
http://www.w3.org/WAI/UA/WD-WAI-UA-BROWSER-19980603/wai-ua-browser.pdf.

In case of a discrepancy between the various formats of the specification, http://www.w3.org/WAI/UA/WD-WAI-UA-BROWSER-19980603 is considered the definitive version.

Comments

Please send detailed comments on this document to w3c-wai-ua@w3.org. Public comments about these guidelines may also be sent to this mailing list.

Table of Contents


1 Rating and Classification

Each guideline is classified according to the following rating system:

[Priority 1]
This guideline must be implemented by a browser, or one or more groups of users will find it impossible to access information in the document. Implementing this guideline will significantly improve access to WWW documents.
[Priority 2]
This guideline should be implemented by a browser, or one or more groups of users will find it difficult to access information in the document. Implementing this guideline will improve access to WWW documents.
[Priority 3]
This guideline should be implemented by a browser to make it easier for one or more groups of users to access information in the document. Implementing this guideline is not critical to accessibility, however.

2 General principles of accessible design

The guidelines in this document have been organized around the following general principles of accessible browser design:

  1. Allow the user to customize the presentation of documents to meet special needs (e.g., only use large fonts, use certain color combinations, present selected information or the focus in a specific way, etc.).
  2. Allow users to override author-specified and browser default styles.
  3. Provide access to alternate representations of information ("alt" text of images, transcripts of video, etc.)
  4. Provide tools to navigate the document: from link to link, form control to form control, frame to frame, etc. Allow navigation with the keyboard at all times.
  5. Provide tools to improve orientation within the document so the user can quickly grasp content and context.
  6. Render a page so that other software -- generically called "third-party assistive technology" -- may interpret the rendered page in a manner useful to the user. A screen reader is one example of such technology; it synthesizes rendered lines of text in succession as speech.

3 Terms and definitions

This document does not specify how browsers should implement the guidelines based on these principles. It does assume that a browser can implement the guidelines based on the characteristics, defined here.

3.1 Documents, elements, and attributes

A document is a series of elements that are defined by a language (e.g., HTML 4.0, an XML application). Each element consists of a name that identifies the type of element, optionally a number of attributes, and a (possibly empty) content. Attributes take values, and some of these values are integral to document accessibility (e.g., the "alt", "title", and "longdesc" attributes in HTML).

The rendered content is that which an element actually causes to be rendered by the user agent. This may differ from the element's content as defined above. For example, some elements cause external data to be rendered (e.g., the IMG element in HTML), and in some cases, browsers may render the value of an attribute (e.g., "alt", "title") in place of the element's content.

3.2 Properties, Values, and Defaults

The presentation of a document is described by properties (e.g., font face, font sizes for different headers, paragraph justification, text color, etc.).

Each property has a current value at any moment (e.g., "Helvetica" for font face, "12 point" for font size, "black" for text color, etc.) The current value comes from one of the following sources: browser, document, or user.

The value given to a property when the browser is first "turned on" is called the default value. Browsers may allow users to change default values through a variety of mechanisms, including the user interface, style sheets, and initialization files.

A property may receive its current value from the document itself, through style sheets associated with the document, presentation attributes of an element, a server, etc. These values are called author styles.

Finally, the user may set the current value through user style sheets or the user interface; these are called user styles. Setting the current value of a property does not change the default value.

3.3 Selection, Focus, and Events

Browsers allow users to interact with the rendered document through several mechanisms.

A selection is a set of elements that the user has identified for a particular operation (typically cut, copy, and paste operations). The selection may be rendered in a manner that distinguishes selected elements from unselected elements (e.g., visually highlighted). Highlighted text is often used by third-party assistive technologies to indicate through speech or Braille output what the user wants read. Most screen readers are sensitive to highlight colors.

The focus describes which control element (link, form, events, etc.) in a view is currently active. A view has only one focus.

Activation means telling the browser to perform a particular operation on the selection or focus.

Events, which may occur to a document or part of a document, cause the browser to behave in a certain way. For instance, an event occurs when a document is loaded into the browser or unloaded, when a mouse button is depressed or released (when released, the browser performs the action specified by the button), when a link is activated (it is generally followed), etc. Events may occur with or without user action, especially with documents using "Dynamic HTML" (DHTML) and scripting programs.

A browser may offer several views of the same document. For instance, one view may show a table of contents and a second the actual contents. Each view may have its own selection, but only one should have the focus at a given moment.

3.4 Description links

A description link, or D-Link, is an author-supplied link to additional information about a piece of content that might otherwise be difficult to access (image, applet, video, etc.). The "WAI Accessibility Guidelines: Page Authoring" document (see [WAI-PAGEAUTH]) describes when and how to insert description links in a document.

4 Presentation Adjustability

4.1 Control over Browser Defaults and Author Styles

  1. [PRIORITY 1]
    Allow the user to override default values for the following properties: font face, font size, foreground and background colors, background images, and selection highlight colors.
  2. [PRIORITY 1]
    Allow the user to override author styles for the following properties: font face, font size, foreground and background colors, background images, and selection highlight colors.
  3. [PRIORITY 3]
    Allow the user, through a keyboard command, to switch between browser default values and user styles.
  4. [PRIORITY 3]
    Allow the user to specify browser default values from an external file. Preferably, this should be done via style sheets.

4.2 Alternative Representations of Images

  1. [PRIORITY 1]
    Allow the user to turn off the display of images inserted by HTML's IMG element (see [HTML40]) and display descriptive text in place of the image. There two potential sources of descriptive text information (in order of preference): the "alt" and "title". The latter may be used as a "tool tip" (information displayed when the user hovers over an element with a pointing device). If both these sources are omitted, the browser should display "Image".

    The entire text should be rendered no matter what the source of the text or the dimensions specified for the original image. Text should be wrapped so the user doesn't need to do a horizontal scroll to read the description.

  2. [PRIORITY 1]
    Allow the user to turn off the display of images inserted by HTML's OBJECT element (see [HTML40]) and display descriptive text in place of the image. The innermost text of the OBJECT is considered its alternative text. If the author has not supplied alternative content the browser should display "Image".

    The entire description text should be rendered no matter what the source of the text or the dimensions specified for the original image. Text should be wrapped so the user doesn't need to do a horizontal scroll to read the description.

  3. [PRIORITY 1]
    When an IMG element has a value for the "longdesc" attribute and the user has turned off the display of images, render a D-link inline to give access to the long description. Provide keyboard access to locate and select the long description (in addition to pointer access for able-bodied users).
  4. [PRIORITY 3]
    When an IMG element has a value for the "longdesc" attribute and the author has already defined a D-link for the image, the "longdesc" D-link should be suppressed. Therefore if an IMG element has both a value for "longdesc" and a hard-coded D-link only one D-link should be presented to the user.
  5. [PRIORITY 3]
    A user selectable option is available to turn off the display of hard-coded D-link in a document. The D-link should assign the valus of "dlink" using the REL attribute of the ANCHOR element. All links using having this attribute would be hidden by the browser.

4.3 Alternative Representations for Sound, Video, Movies, and Animations

  1. [PRIORITY 1]
    Allow the user to turn on audio descriptions of sound, videos, movies, and animations. This would set a flag in the browser that can be used to notify multimedia players to display audio descriptions. Multimedia players need to recognize the flag to render the audio description information.
  2. [PRIORITY 1]
    Allow the user to turn on closed captioning of sound, video, movies, and animations. This would set a flag in the browser that can be used to notify multimedia players to display captioning information for the hearing impaired. Multimedia players need to recognize the flag to render the captioning information. If a system-level flag is available in the operating system to indicate the user's need for closed captioning, the browser flag should default to the system value (i.e., show sounds in Windows 95/NT).

4.4 Alternative Representations of Embedded Applications

  1. [PRIORITY 1]
    Allow the user to turn off the presentation of an applications embedded with the OBJECT element and cause alternative text to be rendered instead. If there is no alternative text, the TITLE attribute can be used as the alternative text. Users with some disabilities may not be able to use an application, but need to know about its existence, purpose, and function.

    The entire text should be rendered no matter what the source of the text or the dimensions specified for the original object. Text should be wrapped so the user doesn't need to do a horizontal scroll to read the description.

    If an OBJECT element could not be loaded, the browser should tell the user why it could not be loaded (e.g., missing object, server not ready, etc.).

  2. [PRIORITY 2]
    Allow the user to turn on the presentation of alternative text simultaneously with the presentation of the embedded applications defined in the OBJECT tag. If there is no alternative text, the TITLE attribute can be used as the alternative text. Users with some disabilities may want both the text descriptive information and the ability to interact with the embedded application.

    The entire text should be rendered no matter what the source of the text or the dimensions specified for the original object. Text should be wrapped so the user doesn't need to do a horizontal scroll to read the description.

    If an OBJECT element could not be loaded, the browser should tell the user why it could not be loaded (e.g., missing object, server not ready, etc.).

  3. [PRIORITY 2]
    Allow the user to turn off the presentation of applications embedded with the APPLET element and cause alternative text to be rendered instead. Note. the APPLET element is deprecated in HTML 4.0 (see [HTML40]) and authors should use the OBJECT element instead.

    Alternate text for the APPLET element is specified with its "alt" attribute.

    If an APPLET element could not be loaded, the browser should tell the user why it could not be loaded.

4.5 Alternative Views of a Document

  1. [PRIORITY 2]
    Allow the user to identify quickly the important elements of a page. For example, when used properly, header elements (H1-H6) may be used to create an outline of major topics. The user should be able to select headers in the outline view, causing the corresponding locations in the main view to be displayed.

    If the browser provides more than one view, the user should be able to toggle between the full and outline view of the document. Selections between views should be synchronized.

  2. [PRIORITY 2]
    Provide a "serialized" view of tables. The first line of the table provides the size and name of a table. Then, for each cell, render the row and column coordinates of the cell followed by the cell's contents. If row and column heading information has been specified in the table (TH element) it should be used in the row and column coordinate information. If no heading information is defined in the table the user should have the option of requesting that the first column and row be used as header information. This is useful for simple tables, where authors have not specified the table header information.
  3. [PRIORITY 2]
    Provide a "serialized", text-only view of page. This means no images, tables, applets, or anything that cannot be rendered as a stream of characters. All non-textual information is hidden and alternative text is used for images and other objects

5 Orientation Information

5.1 Maintenance of Document View and Focus

  1. [PRIORITY 1]
    Remember the focus of each view so that when a user leaves a document and returns, the focus and view are restored. As a user activates links and returns to previously visited documents that their last view and focus in the document remain the same.
  2. [PRIORITY 1]
    Allow the user to specify that the focus in the current view should follow changes in the view. For example, as the user scrolls down the page, the focus might jump to the first element that may take focus that is visible in the view. Thus, after changing the view, if the user uses keyboard commands to move or select the focused element, the view does not abruptly change to another portion of the document with the focused element.

5.2 Frame Focus

  1. [PRIORITY 2]
    When the user selects a link in one frame that causes a new document to be loaded into a different, currently visible frame, move the focus to a location in the new document. If the new document was previously viewed, the last view and element with focus should be used.

5.3 Document Summary Information

  1. [PRIORITY 2]
    When a page is loaded, display short document summary information: the size of the document, the number of structural elements related to the document. The information could be displayed on a status line.
  2. [PRIORITY 2]
    Display short document summary information when requested by the user. A user command would update a status line or open a standard window or dialog box with the document summary information.

5.4 Element and Event Identification

  1. [PRIORITY 2]
    Display information about elements and DHTML events when certain events occur (e.g., focus, hover, etc.). Element information should be displayed on the status line of the browser when an element receives the focus or an event occurs.

5.5 Title Information

  1. [PRIORITY 2]
    Render the content of the TITLE element. The operating system may impose conventions about where and how title information is rendered.

6 Navigation and Control

To navigate a document may involve displaying different parts of it (e.g., by scrolling) or shifting focus to elements of the document. One of the key issues related to navigation and control is the ability to use the keyboard to access all links, form controls and DHTML events. This includes the emulation of DHTML based mouse events.

6.1 Sequential Navigation

  1. [PRIORITY 1]
    Allow the user to use keyboard commands to move sequentially from one frame, link, element with "longdesc" set, or form control to the next.

6.2 Hierarchical Navigation

  1. [PRIORITY 2]
    or [PRIORITY 3]
    Allow the user to use the keyboard to navigate a hierarchical or outline representation of the document. Highlight the focus within the hierarchy in a way that is compatible with third-party assistive technology (see section on compatibility). The user should be able to use keyboard commands to navigate, expand or contract the hierarchy. The hierarchy should be based on structural block level elements like H1-H6, UL, OL, etc.

6.3 Direct Navigation

  1. [PRIORITY 2]
    Allow the user to use the keyboard to move the focus directly to links and controls on a page. Users should be able to search for (and shift the focus to) a link or control by its numerical position (a list of numbered links) or by its name (search for search text matches only in links).
  2. [PRIORITY 2]
    Allow the user to use the keyboard to move the selection directly to elements that are not links or form controls. The selection typically can be tracked by third-party assistive technology to provide alternative presentation of the selection through speech, enlargement or dynamic Braille display.
  3. [PRIORITY 2]
    Allow the user to use the keyboard to move the selection between cells in a table. The selection typically can be tracked by third-party assistive technology to provide alternative presentation of the selection through speech, enlargement or dynamic Braille display.

6.4 Frame Navigation

  1. [PRIORITY 1]
    Allow the user to use the keyboard to move the focus between frames.

6.5 Focus Indication

  1. [PRIORITY 1]
    Provide a means for third-party assistive technologies to identify the focus (see compatibility section for more information.)
  2. [PRIORITY 2]
    Allow the user to adjust the highlight used to indicate the focus element. Can be accomplished by implementing the CSS element focus outline (see section on CSS compatibility).

6.6 Dynamic HTML (DHTML) Events

  1. [PRIORITY 1]
    Provide a means for third-party assistive technologies to identify which elements have associated DHTML events. This maybe done by exposing DHTML events through accessibility APIs.
  2. [PRIORITY 1]
    Allow the user to use keyboard commands to create a list of elements and their associated DHTML events, and to select and execute an event on the list.

6.7 Navigation among Pages

  1. [PRIORITY 2]
    Allow the user to use the keyboard to create a history of visited documents, and to select and visit a document on the list.

7 Visibility of Accessibility Features

7.1 Menu Commands

  1. [PRIORITY 2]
    Display keyboard shortcut navigation commands in menus if the user interface or the operating system supports this.
  2. [PRIORITY 2]
    If menu options exist for element navigation, these menus should also be used to display summary information for elements reached through that menu.

    For example, if a browser has a menu item labeled "Headers", that menu should allow navigation among header elements. The display of the "Headers" menu could read "N Headers" where "N" is the number of headers in the current document. The sub-menu items might include "Next Header", "Previous Header", "All Headers", and a dynamically created list of the first 10 headers in the document.

7.2 Documentation

  1. [PRIORITY 2]
    Provide a description of accessibility features in the on-line documentation. The on-line documentation needs to include information on features that can be used to improve the usability of the browser by persons with disabilities and provide a list of all keyboard commands. The search index should include references to key words like "disability", "handicapped", "accessibility", "impairment", "keyboard" and "shortcut".
  2. [PRIORITY 2]
    Provide a description of accessibility in printed documentation. If printed manuals are distributed with the browser, there should be information about accessibility information in the print manuals. The table of contents and the index should have entries that clearly identify disability access features. The table of contents and index should include references to key words like "disability", "handicapped", "accessibility", "impairment", "keyboard" and "shortcut".
  3. [PRIORITY 2]
    Print and on-line information should be available in alternative formats for people with print impairments. This includes large print, audio tape and Braille. Information on how to obtain information in alternative formats should be available in both on-line and print materials.

8 Compatibility

8.1 Cascading Style Sheets

The following guidelines apply to browsers that implement Cascading Style Sheets (see CSS, level 1 and CSS, level 2. Cascading style sheets may be part of a document or may stand alone and be linked to a source document.

Stand-alone style sheets are useful as "user profiles" in public access computer environments where several people use the same computer. User profiles allow for convenient customization and may be shared by a group.

Overlapping rules from author, user, and browser style sheets cascade (i.e., combine) to produce a single rule that assigns a current value to a property.

  1. [PRIORITY 1]
    Support the :before and :after pseudo-elements as defined in CSS2 ([CSS2], section 12.1) to allow users to label structural elements of a document. The labels can be used to help orient the user to the element that is being spoken or presented in Braille by third-party assistive technology.
  2. [PRIORITY 1]
    Support the outline property as defined in CSS2 ([CSS2], section 18.4) to users to customize the visual indication of the focus element. A personal style sheet or the browser's default style can be used to adjust the focus indication to the preferences of the user.
  3. [PRIORITY 1]
    Allow the user to turn off author styles represented by author style sheets.
  4. [PRIORITY 1]
    Allow the user to adjust default values represented by browser style sheets.
  5. [PRIORITY 2]
    Implement CSS element focus outlines (see [CSS2], section 18.4).
  6. [PRIORITY 2]
    Implement the !important rule as defined in CSS2 ([CSS2], section 6.4.2) to allow users to override author styles and browser defaults
  7. [PRIORITY 2]
    Support aural cascading style sheets (see [CSS2], chapter 19) for the auditory presentation of documents.
  8. [PRIORITY 2]
    Allow the user to specify user styles through style sheets (see [CSS2], section 6.4).

8.2 Compatibility with HTML 4.0

  1. [PRIORITY 1]
    Support the :longdesc attribute defined for IMG elements([HTML 4.0], section 13.2) to provide a means for authors to attatch additional descriptive information to an image.
  2. [PRIORITY 2]
    Support the :rel and :rev attributes defined for Anchors and LINK elements([HTML 4.0], section 12.1.2) to allow users to label D-Links in a document. Borwsers can use this information to hide anochors or links with the "dlink" relationship.
  3. [PRIORITY 2]
    Support the CAPTION element([HTML 4.0], section 11.2.2 ) to allow authors to provide an explicit text title for a table.
  4. [PRIORITY 2]
    Support the NOSCRIPT and NOFRAMESelement([HTML 4.0], section 18.3.1 and 16.4.1 ) to allow authors to provide alternative content for people who use browsers that do not support scripts or frames.
  5. [PRIORITY 3]
    Support the :tabindex attribute defined for the following elements : A, AREA, BUTTON, INPUT, LABEL, and LEGEND, and TEXTAREA.([HTML 4.0], section 17.11.1 ) to allow users assign the order of keyboard navigation through a document.
  6. [PRIORITY 3]
    Support the :accesskey attribute defined for the following elements : A, AREA, BUTTON, INPUT, LABEL, and LEGEND, and TEXTAREA.([HTML 4.0], section 17.11.2) to allow users assign keyboard commands to change the focus and activate a control or anchor

8.3 Compatibility with Third-party Assistive Technology

Standard OS Controls/Menus/Dialog boxes

  1. [PRIORITY 1]
    Use standard rather than custom controls when designing browsers to increase their accessibility. Third-party assistive technology developers are more likely able to access standard controls than custom controls. If you must use custom controls, review them for accessibility and compatibility with third-part assistive technology.

Built-in Accessibility Options

  1. [PRIORITY 1]
    Most popular operating systems have built-in accessibility features. Developers should make sure that their products are compatible with operating system built-in accessibility features. Built-in features typically found on operating systems include: sticky keys, filter keys, toggle keys, high contrast screen colors, system font size and face, and mouse keys. Developers should test there programs with the various features to insure that their technology is compatible with the features available in the operating system. See Appendix A for a list of features available in current operating systems.

Using Accessibility Application Programming Interfaces

  1. [PRIORITY 1]
    Some operating systems have developed accessibility application programming interfaces (APIs). The accessibility APIs are designed to provide a bridge between the standard user interface supported by the operating system and alternative user interfaces developed by third-party assistive technology vendors to provide access to persons with disabilities. Applications supporting these APIs are therefore more compatible with third-party assistive technology. A list of currently available accessibility APIs can be found in Appendix B. There

9 Appendix A: Built-in Accessibility Features of Various Operating Systems

Many major operating systems have built-in accessibility features for improving the usability of the standard operating system by persons with disabilities. When designing an application program, developers should test to see if their product is compatible with the features in the target operating system. This should not be a problem if developers using standard development tools and standard software design practices.

9.1 Microsoft Windows 95 and Windows NT 4.0

The accessibility options can be adjusted from the control panel.

9.2 Apple Macintosh

The accessibility options can be adjusted from the control panels through the Easy Access option and the Closeview option.

9.3 AccessX/SUN Solaris 2.x

Disability access server features, known as AccessX, provide basic workstation accessibility, typically used by people with mobility impairments. AccessX became a supported part of the X Windows server in version X11/R6. The built-in server level access features include:


10 Appendix B: Accessibility APIs for Various Operating Systems

The following is a list of currently public accessibility APIs that are available for various operating systems. The inclusion of this list is not an endorsement of any particular accessibility API by the W3C in general or WAI in particular. The information is purely for reference to browser developers. The use of accessibility APIs is strongly recommended by WAI for compatibility with 3rd party assistive technology. Third-party assistive technology can use the accessibility information provided by the APIs to provide an alternative user interface for various disabilities.

10.1 Microsoft Active Accessibility in Windows 95/NT versions.

When developing new applications for Windows 95/NT, build active accessibility compatibility into the specifications and design. This provides third-party assistive technology developers with important information about your program. More information on active accessibility can be found at the Microsoft WWW site on Active Accessibility.

10.2 SUNSoft Java Accessibility API in Java Code

When developing new applications using SunSoft Java technology, build into the specifications and design the use of the Java Accessibility API. This provides third-party assistive technology with important information for accessibility, so persons with disabilities can use assistive technology to more efficiently access your programs. More information on Java Accessibility API can be found at Java Accessibility Utilities.


11 Appendix C: Closed Captioning Resources

11.1 The following is a list of resources for closed captioning information and service:


12 Acknowledgments

WAI User Agent Working Group Chair:
Jon Gunderson, University of Illinois at Urbana/Champaign
W3C Team contacts:
Judy Brewer and Daniel Dardailler

In addition, we would like to thank the following people who have contributed through review and comment: James Allen, Irene Au, Kitch Barnicle, Kevin Carey, Wendy Chisholm, Chetz Colwell, Neal Ewers, Geoff Freed, Larry Goldberg, Jon Gunderson, Chris Hasser, Phill Jenkins, Leonard Kasday, George Kerscher, Marja-Riitta Koivunen, Josh Krieger, Greg Lowney, Scott Luebking, William Loughborough, Charles McCathieNevile, Masafumi Nakane, Charles Opperman, Mike Paciello, David Pawson, Helen Petrie, David Poehlman, Michael Pieper, Jan Richards, Greg Rosmaita, Liam Quinn, T.V. Raman, Robert Savellis, Constantine Stephanidis, Jim Thatcher, Jutta Treviranus, Steve Tyler, Gregg Vanderheiden, Jaap van Lelieveld, Jon S. von Tetzchner, Ben Weiss, Evan Wies, Chris Wilson, Henk Wittingen, and Tom Wlodkowski.

If you have contributed to the UA guidelines and your name does not appear please contact the editor to add your name to the list.


13 References

[HTML40]
"HTML 4.0 Recommendation", D. Raggett, A. Le Hors, and I. Jacobs, eds. The HTML 4.0 Recommendation is available at:
http://www.w3.org/TR/REC-html40/.
[CSS1]
"CSS, level 1 Recommendation", B. Bos, H. Wium Lie, eds. The CSS1 Recommendation is available at:
http://www.w3.org/TR/REC-CSS1-961217/.
[CSS2]
"CSS, level 2 Recommendation", B. Bos, H. Wium Lie, C. Lilley, and I. Jacobs, eds. The CSS2 Recommendation is available at:
http://www.w3.org/TR/REC-CSS2/.
[WAI-PAGEAUTH]
"WAI Accessibility Guidelines: Page Authoring", G. Vanderheiden, W. Chisholm, and I. Jacobs, eds. These guidelines for designing accessible documents are available at:
http://www.w3.org/TR/WD-WAI-PAGEAUTH.
[CSS2-WAI]
"WAI Resources: CSS2 Accessibility Improvements", I. Jacobs and J. Brewer, eds. This document, which describes accessibility features in CSS2, is available at:
http://www.w3.org/WAI/References/CSS2-access.
[HTML4-WAI]
"WAI Resources: HTML 4.0 Accessibility Improvements", I. Jacobs, J. Brewer, and D. Dardailler, eds. This document, which describes accessibility features in HTML 4.0, is available at:
http://www.w3.org/WAI/References/HTML4-access.

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