WD-WAI-USERAGENT-19980611
WAI Accessibility Guidelines:
User Agent
W3C Working Draft 11-June-1998
- This version:
- http://www.w3.org/WAI/UA/WD-WAI-USERAGENT-19980611
- Latest version:
- http://www.w3.org/WAI/UA/WD-WAI-USERAGENT
- Previous version:
- http://www.w3.org/WAI/UA/WD-WAI-UA-BROWSER-0529.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 user agent designers (e.g.,
browsers) designers for making 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 user agent
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-USERAGENT-19980611
- A plain text file:
- http://www.w3.org/WAI/UA/WD-WAI-USERAGENT-19980611/wai-useragent.txt,
- HTML as a gzip'ed tar file:
- http://www.w3.org/WAI/UA/WD-WAI-USERAGENT-19980611/wai-useragent.tgz,
- HTML as a zip file (this is a '.zip' file not an '.exe'):
- http://www.w3.org/WAI/UA/WD-WAI-USERAGENT-19980611/wai-useragent.zip,
- A gzip'ed PostScript file:
- http://www.w3.org/WAI/UA/WD-WAI-USERAGENT-19980611/wai-useragent.ps.gz,
- A PDF file:
- http://www.w3.org/WAI/UA/WD-WAI-USERAGENT-19980611/wai-useragent.pdf.
In case of a discrepancy between the various formats of the
specification, http://www.w3.org/WAI/UA/WD-WAI-USERAGENT-19980611 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.
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.
The guidelines in this document have been organized around the following
general principles of accessible browser design:
- 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.).
- Allow users to override author-specified and browser default styles.
- Provide access to alternate representations of information ("alt"
text of images, transcripts of video, etc.)
- 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.
- Provide tools to improve orientation within the document so the user
can quickly grasp content and context.
- 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.
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.
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.
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.
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 communicated via an accessibility API.
It 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.
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.
- [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.
- [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.
- [PRIORITY 3]
Allow the user, through a keyboard
command, to switch between browser default
values and user styles.
- [PRIORITY 3]
Allow the user to specify custom
settings in profiles (e.g., external files) that may be shared.
Preferably, this should be done via style sheets.
- [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.
- [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 text content of the OBJECT is
considered its alternative text (see [HTML40],
section 13.3.1 for complete rules about rendering OBJECT elements,
embedded OBJECT elements, etc.).
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.
- [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).
- [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.
- [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.
- [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.
- [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 (e.g.,
show sounds in Windows 95/NT).
- [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.).
- [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.).
- [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.
- [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 alternative views of
the document. Selections between views should be synchronized.
- [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.
- [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
- [PRIORITY 1]
When a user returns to a previously
visited document, the last view and
focus in the document should remain the same.
- [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.
- [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.
- [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.
- [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.
- [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.
- [PRIORITY 2]
Render the content of the TITLE
element in the HEAD block of the document. The operating system
may impose conventions about where and how title information is
rendered.
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.
- [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.
- [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 or pointing input commands to navigate, expand or
contract the hierarchy. The
hierarchy should be based on structural block-level elements like H1-H6,
UL, OL, etc.
- [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 text or alt-text
(search for search text matches only in links).
- [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.
- [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.
- [PRIORITY 1]
Allow the user to use the keyboard to
move the focus between frames.
- [PRIORITY 1]
Provide a means for third-party
assistive technologies to identify the focus
(see compatibility section for
more information.)
- [PRIORITY 2]
Allow the user to adjust the highlight
used to indicate the focus element thick
bordered (box that outlines the item, changing the foreground and
background colors, etc..). Can be accomplished by implementing the CSS
element focus outline (see section on CSS compatibility).
- [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.
- [PRIORITY 1]
Allow the user to use keyboard
commands to browse a list of elements and their associated DHTML
events, and to select and execute an event on
the list.
- [PRIORITY 2]
Allow the user to use the keyboard to
browse a history of visited documents, and to select and visit a
document on the list.
- [PRIORITY 2]
Central dialog box for configuration
of accessibility features available in the user agent.
- [PRIORITY 2]
Predefined accessibility profiles for
common disabilities. The profiles can be modified to tune the
options to a particular persons needs. As much accessibility
configuration should be done through CSS, if the user agent supports
CSS.
- [PRIORITY 2]
Display keyboard shortcut navigation
commands in menus if the user interface or the operating system supports
this.
- [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.
- [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".
- [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".
- [PRIORITY 2]
Print and on-line information should
be available in alternative formats for people with print impairments.
This includes large print, and accessible electronic format,
audio tape, and Braille. Information on how to
obtain information in alternative formats should be available in both
on-line and print materials.
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.
- [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.
- [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.
- [PRIORITY 1]
Allow the user to turn off
author styles represented by author
style sheets.
- [PRIORITY 1]
Allow the user to adjust
default values represented by browser
style sheets.
- [PRIORITY 2]
Implement CSS element focus outlines
(see [CSS2], section 18.4).
- [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
- [PRIORITY 2]
Support aural cascading style sheets
(see [CSS2], chapter 19) for the auditory
presentation of documents.
- [PRIORITY 2]
Allow the user to specify
user styles through style sheets
(see [CSS2], section 6.4).
- [PRIORITY 1]
Support the :longdesc
attribute defined for IMG elements([HTML
4.0], section 13.2) to provide a means for authors to attach
additional descriptive information to an image.
- [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. Browsers can use this
information to hide anchors or links with the "dlink"
relationship.
- [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.
- [PRIORITY 2]
Support the NOSCRIPT
and NOFRAMES element([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.
- [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.
- [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
- [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.
- [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.
- [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 generally
more compatible with third-party assistive
technology. A list of currently available accessibility APIs can be
found in Appendix B.
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.
The accessibility options can be adjusted from the control panel.
- Sticky Keys: Allows user to temporarily hold down shift, alt and
control keys to allow one finger typing.
- Filter Keys: Allows user to change keyboard timing for accepting a
keypress and repeat rate.
- Toggle Keys: Provides auditory feedback when modifier or lock keys
are pressed.
- Mouse Keys: Allows the user to emulate pointer movement and button
press operations using the numeric keypad keys.
- High Contrast Display Mode: Changes the colors used on the display to
a high contrast color combination.
- Sound Sentry: Monitors the system sounds and flashes the menu bar
when sound output is detected. Used by the hearing impaired to know when
sound is being generated by the system.
- Show Sounds: A flag that is available to applications (including
browsers) to notify them to present audio information in a visual form
for the hearing impaired. This requires the application program to
provide the alternative format of information. This can include closed
captioning information on animations and video clips.
The accessibility options can be adjusted from the control panels
through the Easy Access option and the Closeview option.
- Sticky Keys: Allows user to temporarily hold down shift, open apple
and control keys to allow one finger typing.
- Slow Keys: Allows user to change keyboard timing for accepting a
keypress and repeat rate.
- Mouse Keys: Allows the user to emulate pointer movement and button
press operations using the numeric keypad keys.
- Closeview: Closeview is a screen enlargement and enhancement program
used by persons with low vision to magnify the information on the visual
display and change the colors used by the system.
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:
- StickyKeys: Provides locking or latching of modifier keys (eg, Shift,
Control) so that they can be used without simultaneously pressing the
keys being modified. This allows single finger operation of multiple key
combinations.
- RepeatKeys: Delays the onset of key repeat, allowing users with
limited coordination time to release keys before multiple characters are
sent.
- SlowKeys: Requires a key to be held down for a set period before
keypress acceptance. This allows users with limited coordination to
accidentally press keys without sending keypress events.
- MouseKeys: An alternative to the mouse which provides keyboard based
explicit control of cursor movement and all mouse button press/release
events
- ToggleKeys: Indicates locking key state with a tone when pressed,
e.g., Caps Lock.
- BounceKeys: Requires a delay between keystrokes before accepting the
next keypress so users with tremors can prevent the system from
accepting inadvertent keypresses.
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.
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.
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.
- 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.
- [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.