Techniques for User Agent Accessibility Guidelines 1.0

12 September 2001

2 Accessibility topics

This section presents general accessibility techniques that may apply to more than one checkpoint.

2.1 Access to content

User agents need to ensure that users have access to content, either rendered through the user interface or made available to assistive technologies through an API. While providing serial access to a stream of content would satisfy this requirement, this would be analogous to offering recorded music on a cassette: other technologies exist (e.g., CD-ROMs) that allow direct access to music. It is just as important for user agents to allow users to access Web content efficiently, whether the content is being rendered as a two-dimensional graphical layout, an audio stream, or a line-by-line braille stream. Providing efficient access to content involves:

These topics are addressed below.

2.1.1 Preserve and provide structure

When used properly, markup languages structure content in ways that allow user agents to communicate that structure across different renderings. A table describes relationships among cells and headers. Graphically, user agents generally render tables as a two-dimensional grid. However, serial renderings (e.g., synthesized speech and braille) also need to make those relationships apparent, otherwise users may not understand the purpose of the table and the relationships among its cells (see the section on table techniques). User agents need to render content in ways that allow users to understand the underlying document structure, which may consist of headings, lists, tables, synchronized multimedia, link relationships, etc. Providing alternative renderings (e.g., an outline view) will also help users understand document structure.

Note: Even though the structure of a language like HTML may be defined by a Document Type Definition (DTD) or a schema, user agents may convey structure according to a "more intelligent" document model when that model is well-known. For instance, in the HTML DTD, heading elements (H1 - H6) do not nest, but presenting the document as nested headings may convey the document's structure more effectively than as a flat list of headers.

2.1.2 Allow access to selected content

The guidelines emphasize the importance of navigation as a way to provide efficient access to content. Navigation allows users to access content more efficiently and, when used in conjunction with selection and focus mechanisms, allows users to query content for metadata. For instance, blind users often navigate a document by skipping from link to link, deciding whether to follow each link based on metadata about the link. User agents can help them decide whether to follow a link by allowing them to query each focused link for the link text, title information, information about whether the link has been visited, whether the link involves a fee, etc. While much of this information may be rendered, the information has to also be available to assistive technologies.

For example, the Amaya browser/editor [AMAYA] makes available all attributes and their values to the user through a context menu. The user selects an element and opens an attribute menu that shows which attributes are available for the element and which have been assigned values. The user may read or write values to attributes (since Amaya is an editor as well as a browser). Information about attributes is also available through Amaya's structured view, which renders the document tree as structured text.

The selection may be widened (moved to the nearest node one level up the document tree) by pressing the Escape key; this is a form of structured navigation based on the underlying document object model.

Users may want to select content based on structure alone (as offered by Amaya) but also based on how the content has been rendered. For instance, most user agents allow users to select ranges of rendered text that may cross "element boundaries".

2.1.3 Context

Authors and user agents provide context to users through content, structure, navigation mechanisms, and query mechanisms. Titles, dimensions, dates, relationships, the number of elements, and other metadata all help orient the user, particularly when available as text. For instance, user agents can help orient users by allowing them to request that document headings and lists be numbered. See also the section on table techniques, which explains how user agents can offer table navigation and the ability to query a table cell for information about the cell's row and column position, associated header information, etc.

2.2 User control of rendering and style

To ensure accessibility, users need to be able to configure the style of rendered content and the user interface. Author-specified styles, while important, may make content inaccessible to some users. User agents need to allow users to increase the size of rendered text (e.g., with a zoom mechanism or font size control), to change colors and color combinations, to slow down multimedia presentations, etc.

To give authors design flexibility and allow users to control important aspects of content style, user agents should implement CSS ([CSS1], [CSS2]) and allow users to create and apply user style sheets. CSS includes mechanisms for tailoring rendering for a particular output medium, including audio, braille, screen, and print.

2.3 Link techniques

User agents make links accessible by providing navigation to links, helping users decide whether to follow them, and allowing interaction in a device-independent manner. Link techniques include the following:

JAWS for Windows HTML Options menu, which allows configuration of a number of link rendering options

As shown in the following image, JAWS for Windows [JFW] offers a view for configuring a number of rendering features, notably some concerning link types, text link verbosity, image map link verbosity, graphical link verbosity, and internal links.

2.4 List techniques

User agents can make lists accessible by ensuring that list structure – and in particular, embedded list structure – is available through navigation and rendering.

2.5 Table techniques

The HTML TABLE element was designed to represent relationships among data ("data" tables). Even when authored well and used according to format specification, tables may pose problems for users with disabilities for a number of reasons:

For these situations, user agents may assist these users by providing table navigation mechanisms and supplying context that is present in a two-dimensional rendering (e.g., the cells surrounding a given cell).

To complicate matters, many authors use tables to lay out Web content ("layout" tables). Not only are table structures used to lay out objects on the screen, table elements such as TH (table header) in HTML are used to font styling rather than to indicate a true table header. These practices make it difficult for assistive technologies to rely on markup to convey document structure. Consequently, assistive technologies often resort to interpreting the rendered content, even though the rendered content has "lost" information encoded in the markup. For instance, when an assistive technology "reads" a table from its graphical rendering, the contents of multiline cells may become intermingled. For example, consider the following table:

This is the top left cell    This is the top right cell 
of the table.                of the table.

This is the bottom left      This is the bottom right 
cell of the table.           cell of the table.

Screen readers that read rendered content line by line would read the table cells incorrectly as "This is the top left cell This is the top right cell". So that assistive technologies are not required to gather incomplete information from renderings, these guidelines require that user agents provide access to content through an API (see checkpoint 6.3).

The following sections discuss techniques for providing improved access to tables.

2.5.1 Table metadata

Users of screen readers or other serial access devices cannot gather information "at a glance" about a two-dimensional table. User agents can make tables more accessible by providing the user with table metadata such as the following:

When navigating, quick access to table metadata will allow users to decide whether to navigate within the table or skip over it. Other techniques:

2.5.2 Linear rendering of tables

A linear rendering of tables – cells presented one at a time, row by row or column by column – may be useful, but generally only for simple tables. For more complex tables, user agents need to convey more information about relationships among cells and their headers. A linear rendering of a table may be useful as an equivalent for a multi-dimensional table.

Note: The following techniques apply to columns as well as rows. The elements listed in this section are HTML 4.01 table elements ([HTML4], section 11).

2.5.3 Cell rendering

The most important aspect of rendering a table cell is that the cell's contents be rendered faithfully and be identifiable as the contents of a single cell. However, user agents may provide additional information to help orient the user:

2.5.4 Cell header algorithm

Properly constructed data tables distinguish header cells from data cells. How headers are associated with table cells depends on the markup language. The following algorithm is based on the HTML 4.01 algorithm to calculate header information ([HTML4], section 11.4.3). For the sake of brevity, it assumes a left-to-right ordering, but will work for right-to-left tables as well (refer to the "dir" attribute of HTML 4 [HTML4], section 8.2). For a given cell:

2.5.5 Cell header repair strategies

Not all data tables include proper header markup, which the user agent may be able to detect. Some repair strategies for finding header information include the following:

Other repair issues to consider:

2.5.6 Table navigation

To permit efficient access to tables, user agents should allow users to navigate to tables and within tables, to select individual cells, and to query them for information about the cell and the table as a whole.

2.6 Image map techniques

One way to make an image map accessible to some users (e.g., users with blindness) is to render the links it contains as text links. This allows assistive technologies to render the links as synthesized speech or braille, and benefits users with slow access to the Web and users of small Web devices that do not support images but can support hypertext. User agents may allow users to toggle back and forth between a graphical mode for image maps and a text mode.

To construct a text version of an image map in HTML:

Furthermore, user agents that render a text image map instead of an image may preface the text image map with inline metadata such as:

Allow users to suppress, shrink, and expand text versions of image maps so that they may quickly navigate to an image map (which may be, for example, a navigation tool bar) and decide whether to "expand" it and follow the links of the map. The metadata listed above will allow users to decide whether to expand the map. Ensure that the user can expand and shrink the map and navigate its links using the keyboard and other input devices.

2.7 Frame techniques

Frames were originally designed so that authors could divide up graphic real estate and allow the pieces to change independently (e.g., selecting an entry in a table of contents in one frame changes the contents of a second frame). While frames are not inherently inaccessible, they raise some accessibility issues:

To name a frame in HTML, use the following algorithm:

  1. Use the "title" attribute on FRAME, or if not present,
  2. Use the "name" attribute on FRAME, or if not present,
  3. Use title information of the referenced frame source (e.g., the TITLE element of the source HTML document), or
  4. Use title information of the referenced long description (e.g., what "longdesc" refers to in HTML), or
  5. Use frame context (e.g., "Frame 2.1.3" to indicate the path to this frame in nested framesets).

To make frames accessible, user agents should do the following:

Consider renderings of the following document:


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN">
<HTML lang="en">
  <META http-equiv="Content-Type" 
           content="text/html; charset=iso-8859-1">
  <TITLE>Time Value of Money</TITLE>

<FRAMESET COLS="*, 388">
  <FRAMESET ROWS="51, *">
    <FRAME src="sizebtn" marginheight="5" marginwidth="1" 
       name="Size buttons" title="Size buttons">
    <FRAME src="outlinec" marginheight="4" marginwidth="4" 
       name="Presentation Outline" 
           title="Presentation Outline">

  <FRAMESET ROWS="51, 280, *">
    <FRAME src="navbtn" marginheight="5" marginwidth="1" 
       name="Navigation buttons" 
       title="Navigation buttons">
    <FRAME src="slide001" marginheight="0" marginwidth="0" 
      name="Slide Image" title="Slide Image">
    <FRAME src="note001" name="Notes" title="Notes">
<P>List of Presentation Slides</P>
<LI><A HREF="slide001">Time Value of Money</A>
<LI><A HREF="slide002">Topic Overview</A>
<LI><A HREF="slide003">Terms and Short Hand</A>
<LI><A HREF="slide004">Future Value of a Single CF</A>
<LI><A HREF="slide005">Example 1: FV example:The
NBA’s new Larry Bird exception</A>
<LI><A HREF="slide006">FV Example: NBA’s Larry
Bird Exception (cont.)</A>
<LI><A HREF="slide007">SuperStar’s Contract
<LI><A HREF="slide008">Present Value of a Single
Cash Flow</A>
<LI><A HREF="slide009">Example 2: Paying Jr, and
<LI><A HREF="slide010">Example 3: Finding Rate of
Return or Interest Rate</A>
<LI><A HREF="slide011">Annuities</A>
<LI><A HREF="slide012">FV of Annuities</A>
<LI><A HREF="slide013">PV of Annuities</A>
<LI><A HREF="slide014">Example 4: Invest Early in
an IRA</A>
<LI><A HREF="slide015">Example 4 Solution</A>
<LI><A HREF="slide016">Example 5: Lotto Fever
<LI><A HREF="slide017">Uneven Cash Flows: Example
6:Fun with the CF function</A>
<LI><A HREF="slide018">Example 6 CF worksheet inputs</A>
<LI><A HREF="slide019">CF inputs continued</A>
<LI><A HREF="slide020">Non-Annual Interest
<LI><A HREF="slide021">Example 7: What rate are
you really paying?</A>
<LI><A HREF="slide022">Nominal to EAR Calculator</A>
<LI><A HREF="slide023">Continuous Interest Compounding</A>
<LI><A HREF="slide024">FV and PV with non-annual
interest compounding</A>
<LI><A HREF="slide025">Non-annual annuities</A>
<LI><A HREF="slide026">Example 8: Finding Monthly
Mortgage Payment</A>
<LI><A HREF="slide027">solution to Example 8</A>

The following examples show how some user agents handle this frameset.

Example frameset with five frame panes rendered in Microsoft Internet Explorer 5.0

Rendering of a frameset by Internet Explorer [IE-WIN].

Rendering by Lynx [LYNX]:


                                        Time Value of Money

   FRAME: Size buttons
   FRAME: Presentation Outline
   FRAME: Navigation buttons
   FRAME: Slide Image
   FRAME: Notes

   List of Presentation Slides
    1. Time Value of Money 
    2. Topic Overview 
    3. Terms and Short Hand 
    4. Future Value of a Single CF 
    5. Example 1: FV example:The NBA's new Larry Bird exception 
    6. FV Example: NBA's Larry Bird Exception (cont.) 
    7. SuperStar's Contract Breakdown 
    8. Present Value of a Single Cash Flow 
    9. Example 2: Paying Jr, and A-Rod 
   10. Example 3: Finding Rate of Return or Interest Rate 
   11. Annuities 
   12. FV of Annuities 
   13. PV of Annuities 
   14. Example 4: Invest Early in an IRA 
   15. Example 4 Solution 
   16. Example 5: Lotto Fever 
   17. Uneven Cash Flows: Example 6:Fun with the CF function 
   18. Example 6 CF worksheet inputs 
   19. CF inputs continued 
   20. Non-Annual Interest Compounding 
   21. Example 7: What rate are you really paying? 
   22. Nominal to EAR Calculator 
   23. Continuous Interest Compounding 
   24. FV and PV with non-annual interest compounding 
   25. Non-annual annuities 
   26. Example 8: Finding Monthly Mortgage Payment 
   27. solution to Example 8 

Example frameset with five links for each of the frame elements in IBM home page reader

Rendering of a frameset by Home Page Reader [HPR].

User agents may also indicate the number of frames in a document and which frame has the current focus via the menu bar or popup menus. Users can configure the user agent to include a FRAMES menu item in their menu bar. The menu bar makes the information highly visible to all users and is very accessible to assistive technologies.

A pull down menu indicating the number of frames in a document, the labels associated with each frame, and a check mark to indicate the frame with the current focus

In this image of the Accessible Web Browser [AWB], the menu bar indicates the number of frames and uses a check mark next to the name of the frame with the current focus.

2.8 Form techniques

To make a form accessible, the user agent needs to ensure that:

2.8.1 Form navigation techniques

2.8.2 Form orientation techniques

Provide the following information about forms on demand:

2.8.3 Form element orientation techniques

In conjunction with navigation:

Provide the following information about the elements in a form on demand (e.g., for the element with focus):

2.9 Generated content techniques

User agents may help orient users by generating additional content that "announces" a context change. This may be done through CSS 2 [CSS2] style sheets using a combination of selectors (including the ':before' and ':after' pseudo-elements described in section 12.1) and the 'content' property (section 12.2).

For instance, the user might choose to hear "language:German" when the natural language changes to German and "language:default" when it changes back. This may be implemented in CSS 2 with the ':before' and ':after' pseudo-elements ([CSS2], section 5.12.3)


With the following definition in the stylesheet:

    [lang|=es]:before { content: "start Spanish "; }
    [lang|=es]:after  { content: " end Spanish"; }

the following HTML example:

<p lang="es" class="Spanish">
 <a href="foo_esp.html" 
    hreflang="es">Esta pagina en español</a></p>

might be spoken "start Spanish _Esta pagina en espanol_ end Spanish". Refer also to information on matching attributes and attribute values useful for language matching in CSS 2 ([CSS2], section 5.8.1).

The following example uses style sheets to distinguish visited from unvisited links with color and a text prefix.


The phrase "Visited link:" is inserted before every visited link:

    A:link           { color: red }     /* For unvisited links */
    A:visited        { color: green }   /* For visited links */
    A:visited:before { content: "Visited link: " }

To hide content, use the CSS 'display' or 'visibility' properties ([CSS2], sections 9.2.5 and 11.2, respectively). The 'display' property suppresses rendering of an entire subtree. The 'visibility' property causes the user agent to generate a rendering structure, but the content is invisible.

The following XSLT style sheet (excerpted from the XSLT Recommendation [XSLT], Section 7.7) shows how one might number H4 elements in HTML with a three-part label.


<xsl:template match="H4">
     <xsl:number level="any" from="H1" count="H2"/>
     <xsl:number level="any" from="H2" count="H3"/>
     <xsl:number level="any" from="H3" count="H4"/>
     <xsl:text> </xsl:text>

End example.

2.10 Content repair techniques

When generating repair content, user agent developers should consider the following issues:

See also the section on table cell header repair strategies. Refer also to the W3C document "Techniques for Authoring Tool Accessibility Guidelines 1.0" [ATAG10-TECHS].

2.11 Script and applet techniques

User agents need to make dynamic content accessible to users who may be disoriented by changes in content, who may have a physical disability that prevents them from interacting with a document within a time interval specified by the author, or whose user agent does not support scripts or applets. Not only do user agents make available equivalents to dynamic content, they have to allow users to turn off scripts, to stop animations, adjust timing parameters, etc. Some user agents also allow users to turn off scripts for security reasons.

2.11.1 Script techniques

Certain elements of a markup language may have associated event handlers that are activated when certain events occur. User agents need to be able to identify those elements with event handlers statically associated (i.e., associated in the content, not in a script). In HTML 4 ([HTML4], section 18.2.3), intrinsic events are specified by the attributes beginning with the prefix "on": "onblur", "onchange", "onclick", "ondblclick", "onkeydown", "onkeypress", "onkeyup", "onload", "onmousedown", "onmousemove", "onmouseout", "onmouseover", "onmouseup", "onreset", "onselect", "onsubmit", and "onunload".

Techniques for providing access to scripts include the following:

2.11.2 Applet techniques

When a user agent loads an applet, it should support the Java system conventions for loading an assistive technology (see the appendix on loading assistive technologies for DOM access). If the user is accessing the applet through an assistive technology, the assistive technology should alert the user when the applet receives content focus as this will likely result in the launch of an associated plug-in or browser-specific Java Virtual Machine. The user agent then needs to turn control of the applet over to the assistive technology. User agents need to make conditional content available to the assistive technology. Applets generally include an application frame that provides title information.

2.12 Input configuration techniques

User agents that allow users to modify default input configurations need to account for configuration information from several sources: user agent defaults, user preferences, author-specified configurations, and operating environment conventions. In HTML, the author may specify keyboard bindings with the "accesskey" attribute ([HTML4], section 17.11.2). Users generally specify their preferences through the user interface but may also do so programmatically or through a profile. The user agent may also consider user preferences set at the operating environment level.

To the user, the most important information is the final configuration once all sources have been cascaded (combined) and all conflicts resolved. Knowing the default configuration is also important; checkpoint 12.3 requires that the default configuration be documented. The user may also want to know how the current configuration differs from the default configuration and what configuration in the viewport with the current focus comes from the author. This information may also be useful to technical support personnel who may be assisting users.

2.12.1 Resolution of input configuration conflicts

In general, user preferences should override other configurations, however this may not always be desirable. For example, users should be prevented from configuring the user agent in a way that would interfere with important functionalities such as quitting the user agent or reconfiguring it.

Some options for resolving conflicts:

2.13 Synthesized speech techniques

The following techniques apply to user agents that render content as synthesized speech.


2.14 Techniques for reducing dependency on spatial interactions

Some interactions with content may require spatial information, often provided by users without disabilities through a pointing device such as a mouse.

2.15 Accessibility and internationalization techniques

The following techniques may be considered when integrating accessibility features and internationalization.

2.16 Appendix: Impact matrix

This matrix summarizes which checkpoints are expected to benefit users with certain types of disabilities. For more information about types of disabilities, assistive technologies, access strategies, and more, refer to "How People with Disabilities Use the Web" [PWD-USE-WEB].

seizure disorder
3.3, 3.4
2.1, 2.3, 4.17, 6.1, 6.2, 6.3, 6.4, 6.5, 6.6, 6.7, 6.8, 6.9, 7.1, 7.2, 7.3, 7.4, 8.1, 8.2, 12.1, 12.2, 12.3, 12.4, 12.5
4.4, 4.7, 4.8, 4.15
2.6, 2.10, 3.1, 3.2, 3.3, 3.5, 3.6, 3.7, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7, 4.8, 4.15, 5.1, 5.2, 5.3, 5.4, 5.5, 5.6, 5.7, 9.4, 9.8, 9.10, 10.5, 10.6, 10.8, 11.1, 11.2, 11.3, 11.4, 11.5, 11.6, 11.7
1.3, 2.2, 2.5, 2.6
9.4, 9.10, 10.5, 10.6, 11.1, 11.2, 11.3, 11.4, 11.5, 11.6, 11.7
low vision
2.2, 2.5, 2.7, 2.8, 2.9, 3.2, 3.3, 3.5, 3.6, 4.1, 4.2, 4.4, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12, 4.13, 4.14, 4.15, 4.16, 5.1, 5.4, 9.1, 9.2, 9.3, 9.4, 9.7, 9.8, 9.10, 10.4, 10.5, 10.6, 10.7
1.1, 1.2, 1.3, 2.2, 2.4, 2.5, 2.7, 2.8, 2.9, 2.11, 3.2, 3.3, 3.5, 3.6, 4.4, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12, 4.13, 4.14, 4.15, 4.16, 5.1, 5.3, 5.4, 5.5, 9.1, 9.2, 9.3, 9.4, 9.5, 9.6, 9.7, 9.8, 9.9, 9.10, 10.4, 10.5, 10.6, 10.7, 10.8, 11.1, 11.2, 11.3, 11.5, 11.6, 11.7
color deficiency
3.1, 4.3, 10.2, 10.4, 10.7
1.1, 1.2, 2.4, 2.9, 2.11, 5.3, 5.5, 5.6, 9.1, 9.2, 9.3, 9.4, 9.5, 9.6, 9.7, 9.8, 9.9, 9.10, 10.5, 10.6, 11.1, 11.2, 11.3, 11.4, 11.5, 11.6, 11.7
hard of hearing
1.3, 2.2, 2.5, 2.6, 4.9

2.17 Appendix: Accessibility features of some operating systems

Several operating systems include built-in accessibility features designed to assist individuals with varying abilities. Despite operating systems differences, the built-in accessibility features use a similar naming convention and offer similar functionalities, within the limits imposed by each operating system (or particular hardware platform). The following is a list of built-in accessibility features from several platforms:

StickyKeys allows users who have difficulties with pressing several keys simultaneously to press and release sequentially each key of the configuration.
These allow users to move the mouse cursor and activate the mouse button(s) from the keyboard.
RepeatKeys allows users to set how fast a key repeats ("repeat rate") when the key is held pressed. It also allows users to control how quickly the key starts to repeat after the key has been pressed ("delay until repeat"). Users can also turn off key repeating.
SlowKeys instructs the computer not to accept a key as pressed until it has been pressed and held down for more than a user-configurable length of time.
BounceKeys prevents extra characters from being typed if the user bounces (e.g., due to a tremor) on the same key when pressing or releasing it.
ToggleKeys provides an audible indication for the status of keys that have a toggled state (keys that maintain status after being released). The most common toggling keys include Caps Lock, Num Lock, and Scroll Lock.
SoundSentry monitors the operating system and applications for sounds in order to provide a graphical indication when a sound is being played. Older versions of SoundSentry may have flashed the entire display screen for example, while newer versions of SoundSentry provide the user with a selection of options, such as flashing the viewport that has the current focus or flashing the active window caption bar.

The next three built-in accessibility features are not as commonly available as the above group of features, but are included here for definition, completeness, and future compatibility.

ShowSounds are user settings or software switches that cause audio to be presented using both audio and graphics. Applications may use these switches as the basis of user preferences.
HighContrast sets fonts and colors designed to make the screen easier to read.
TimeOut turns off built-in accessibility features automatically if the computer remains idle for a user-configurable length of time. This is useful for computers in public settings such as a library. TimeOut might also be referred to as "reset" or "automatic reset".

The next accessibility feature listed here is not considered to be a built-in accessibility feature (since it only provides an alternative input channel) and is presented here only for definition, completeness, and future compatibility.

SerialKeys allows a user to perform all keyboard and mouse functions from an external assistive device (such as communication aid) communicating with the computer via a serial character stream (e.g., serial port, infra-red port, etc.) rather than or in conjunction with, the keyboard, mouse, and other conventional input devices/methods.

Microsoft Windows 95, Windows 98, and Windows NT 4.0

The following accessibility features can be adjusted from the Accessibility Options Control Panel:

Additional accessibility features available in Windows 98:

Magnifier is a windowed, screen enlargement and enhancement program used by people with low vision to magnify an area of the graphical display (e.g., by tracking the text cursor, current focus, etc.). Magnifier can also invert the colors used by the system within the magnification window.
Accessibility Wizard
The Accessibility Wizard is a setup tool to assist users with the configuration of system accessibility features.


Apple Macintosh operating system

The following accessibility features can be adjusted from the Easy Access Control panel. Note: The Apple naming convention for accessibility features is to put spaces between the terms (e.g., "Sticky Keys" instead of "StickyKeys").

The following accessibility features can be adjusted from the Keyboard Control Panel.

The following accessibility feature can be adjusted from the Sound or Monitors and Sound Control Panel (depending on system version).

Additional accessibility features available for the Macintosh OS:

CloseView is a full screen, screen enlargement and enhancement program used by people with low vision to magnify the information on the graphical display, and it can also change the colors used by the system.
SerialKeys is available as freeware from Apple and several other Web sites.

AccessX, X Keyboard Extension (XKB), and the X Window System

The following accessibility features can be adjusted from the AccessX graphical user interface X client on some DEC, SUN, and SGI operating systems. Other systems supporting XKB may require the user to manipulate the features via a command line parameter(s).

Note: AccessX became a supported part of the X Window System X Server with the release of the X Keyboard Extension in version X11R6.1

DOS (Disk Operating System)

The following accessibility features are available from a freeware program called AccessDOS, which is available from several Internet Web sites including IBM, Microsoft, and the Trace Center, for either PC-DOS or MS-DOS versions 3.3 or higher.

2.18 Appendix: Loading assistive technologies for access to the document object model

Many of the checkpoints in the guidelines require a "host" user agent to communicate information about content and the user interface to assistive technologies. This appendix explains how developers can ensure the timely exchange of this information (see checkpoint 6.9). The techniques described here include:

  1. Loading the entire assistive technology in the address space of the host user agent;
  2. Loading part of the assistive technology in the address space of the host user agent (e.g., piece of stub code, a dynamically linked library (DLL), a browser helper object, etc.);
  3. Out-of-process access to the document object model.

The first two techniques are similar, differing in the amount of, or capability of, the assistive technology loaded in the same process or address space as the host user agent. These techniques are likely to provide faster access to the document object model since they will not be subject to inter-process communication overhead.

Note: This appendix does not address specialized user agents.

Loading assistive technologies for direct navigation of the document object model

First, the host user agent needs to know which assistive technology to load. One technique for this is to store a reference to an assistive technology in a system registry file or, in the case of Java, a properties file. Registry files are common among many operating system platforms:

Here is an example entry for Java:

In Microsoft Windows, a similar technique could be followed by storing the name of a Dynamic Link Library (DLL) for an assistive technology in a designated assistive technology key name/assistive technology pair.

Here is an example entry for Windows:

           "ScreenReader, VoiceNavigation"

Attaching the assistive technologies to the document object model

Once the assistive technology has been registered, any other user agent can determine whether it needs to be loaded and then load it. Once loaded, the assistive technology can monitor the document object model as needed.

On a non-Java platform, a technique to do this would be to create a separate thread with a reference to the document object model using a DLL. This new thread will load the DLL and call a specified DLL entry name with a pointer to the document object model interface. The assistive technology process will then run as long as required.

The assistive technology has the option to either:

In the future, it will be necessary to provide a more comprehensive reference to the application that not only provides direct navigation to its client area document object model, but also multiple document object models that it is processing and an event model for monitoring them.

Java's direct access

Java can facilitate timely access to accessibility components. In this example, an assistive technology running on a separate thread monitors user interface events such as focus changes. When focus changes, the assistive technology is alerted of which component object has focus. The assistive technology can communicate directly with all components in the application by walking the parent/child hierarchy and connecting to each component's methods and monitor events directly. In this case, an assistive technology has direct access to component specific methods as well as those provided for by the Java Accessibility API. There is no reason that a document object model interface to user agent components could not be provided via Java.

In Java 1.1.x, Sun's Java access utilities load an assistive by monitoring the Java file for the presence of assistive technologies and loads them as shown in the following code example:


import java.awt.*;
import java.util.*;
String atNames = Toolkit.getProperty("AWT.assistive_technologies",null);
if (atNames != null) {
    StringTokenizer parser = new StringTokenizer(atNames," ,");
    String atName;
    while (parser.hasMoreTokens()) {
       atName = parser.nextToken();
       try {
       catch (ClassNotFoundException e) {
          throw new AWTError("Assistive Technology not found: " + atName);
       catch (InstantiationException e) {
          throw new AWTError("Could not instantiate Assistive" + 
                             " Technology: " + atName);
       catch (IllegalAccessException e) {
          throw new AWTError("Could not access Assistive" + 
                             " Technology: " + atName);
       } catch (Exception e) {
          throw new AWTError("Error trying to install Assistive" + 
                             " Technology: " + atName + " " + e);

In the above code example, the function Class.forName(atName).newInstance() creates a new instance of the assistive technology. The constructor for the assistive technology will then be responsible for monitoring application component objects by monitoring system events.

In the following code example, the constructor for the assistive technology, AccessEngine, adds a focus change listener using Java accessibility utilities. When the assistive technology is alerted that an object has received focus, it has direct access to that object. If the Object, o, has implemented a document object model interface, the assistive technology will have direct access to the document object model in the same process space as the application.


   import java.awt.*;
   import javax.accessibility.*;
   import java.awt.event.FocusListener;

   class AccessEngine implements FocusListener {
      public AccessEngine() {
         //Add the AccessEngine as a focus change listener
      public void focusGained(FocusEvent theEvent) {
         // get the component object source
         Object o = theEvent.getSource();
         // check to see if this is a document object model component
         if (o instanceof DOM) {
      public void focusLost(FocusEvent theEvent) {
         // Do Nothing

In this example, the assistive technology has the option of running stand-alone or acting as a cache for a bridge that communicates with a main assistive technology running outside the Java virtual machine.

Loading part of the assistive technologies for direct access to the document object model

In order to attach to a running instance of Internet Explorer 4.0, you can use a Browser Helper Object ([BHO]), which is a DLL that will attach itself to every new instance of Internet Explorer 4.0 [IE-WIN] (only if you run iexplore.exe). You can use this feature to gain access to the object model of Internet Explorer and to monitor events. This can be tremendously helpful when many method calls need to be made to IE, as each call will be executed much more quickly than the out of process case.

There are some requirements when creating a Browser Helper Object:

Java access bridge

To provide native Microsoft Windows assistive technologies access to Java applications without creating a Java native solution, Sun Microsystems provides the "Java Access Bridge." This bridge is loaded as an assistive technology as described in the section on loading assistive technologies for direct navigation of the document object model. The bridge uses a Java Native Invocation (JNI) to Dynamic Link Library (DLL) communication and caching mechanism that allows a native assistive technology to gather and monitor accessibility information in the Java environment. In this environment, the assistive technology determines that a Java application or applet is running and communicates with the Java Access Bridge DLL to process accessibility information about the application/applet running in the Java Virtual Machine.

Loading assistive technologies for indirect access to the document object model

Access to application specific data across process boundaries or address space might be costly in terms of performance. However, there are other reasons to consider when accessing the document object model that might lead a developer to wish to access it from their own process or memory address space. One obvious protection this method provides is that, if the user agent fails, it does not disable the user's assistive technology as well. Another consideration would be legacy systems, where the user relies on their assistive technology for access to software other than the user agent, and thus would have their application loaded all the time.

There are several ways to gain access to the user agent's document object model. Most user agents support some kind of external interface, or act as a mini-server to other applications running on the desktop. Internet Explorer [IE-WIN] is a good example of this, as IE can behave as a component object model (COM) server to other applications. Mozilla [MOZILLA], the open source release of Navigator also supports cross platform COM (XPCOM).

The following example illustrates the use of COM to access the IE object model. This is an example of how to use COM to get a pointer to the WebBrowser2 module, which in turn enables access to an interface/pointer to the document object, or IE document object model for the content.


   /* first, get a pointer to the WebBrowser2 control */
   if (m_pIE == NULL) {
      hr = CoCreateInstance(CLSID_InternetExplorer, 
           NULL, CLSCTX_LOCAL_SERVER, IID_IWebBrowser2, 

      /* next, get a interface/pointer to the document in view, 
         this is an interface to the document object model (DOM)*/

      void CHelpdbDlg::Digest_Document() {
         HRESULT hr;
         if (m_pIE != NULL) {
            IDispatch* pDisp;
            hr = m_pIE->QueryInterface(IID_IDispatch, (void**) &pDisp);
            if (SUCCEEDED(hr)) {
               IDispatch* lDisp;
               hr = m_pIE->get_Document(&lDisp);
               if (SUCCEEDED(hr)) {
                   IHTMLDocument2* pHTMLDocument2;
                   hr = lDisp->QueryInterface(IID_IHTMLDocument2,
                               (void**) &pHTMLDocument2);
                   if (SUCCEEDED(hr)) {
                   /* with this interface/pointer, IHTMLDocument2*,
                      you can then work on the document */
                      IHTMLElementCollection* pColl;
                      hr = pHTMLDocument2->get_all(&pColl);
                      if (SUCCEEDED(hr)) {
                         LONG c_elem;
                         hr = pColl->get_length(&c_elem);
                         if (SUCCEEDED(hr)) {
                            FindElements(c_elem, pColl);

For a working example of this method, refer to HelpDB [HELPDB].