Techniques for User Agent Accessibility Guidelines 1.0

16 October 2002

3 Accessibility topics

This section presents general techniques that may be relevant to more than one checkpoint. This section is not written in terms of the requirements of the checkpoints. Instead, it is organized according to other topics that should also be familiar to user agent designers.

3.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 series of lines of braille. Providing efficient access to content involves:

These topics are addressed below.

Note: Throughout this document, the term context menu refers to a user interaction mechanism whereby:

  1. The user designates a piece of content (e.g., with the selection or focus).
  2. The user invokes a menu (e.g., through a keyboard shortcut) consisting of options determined by the context selected by the user. For instance, if the user has selected an HTML table cell, the context menu might offer information about associated headers.

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, relationships also have to be apparent for users with serial access to content or who navigate sequentially, 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, and link relationships. 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 4 [HTML4] and XHTML 1.0 [XHTML10] DTDs, 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.

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, and information about whether the link has been visited. 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" (e.g., to select part of a paragraph that includes a phrase that is emphasized).

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 and associated headers.

3.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 scale of rendered text, to change colors and color combinations, and to slow down multimedia presentations.

Cascading Style Sheets (CSS, defined in [CSS1] and [CSS2]) give authors design flexibility and allow users to control important aspects of content style; see checkpoint 4.14 for information about allowing users to choose from among available style sheets. CSS includes mechanisms for tailoring rendering for a particular output medium, including audio, braille, screen, and print.

3.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 image above, 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.

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

3.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 arrange objects horizontally and vertically on the screen, table elements such as TH (table header) in HTML are used to change the style of text (as table headers are often rendered in bold fonts) 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.

Table metadata

Users with serial access to content or who navigate sequentially 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:

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

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:

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 also work (with minor modifications) for right-to-left tables (refer to the "dir" attribute of HTML 4 [HTML4], section 8.2). For a given cell:

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:

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.

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

3.7 Frame techniques

HTML frames (see, for example, the FRAME and IFRAME elements in HTML 4 [HTML4]) 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:

The following screen shot illustrates how Home Page Reader [HPR] renders a frameset by allowing the user to navigate (on the left side) to each of five frames in a frameset.

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

The next screen shot illustrates how the user agent can provide information about the number and structure of frames in the user agent user interface.

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. The menu bar makes the information highly visible to all users and is very accessible to assistive technologies.

3.8 Form techniques

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

Form navigation techniques

Form orientation techniques

Provide the following information about forms on demand:

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):

3.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)

Example.

With the following definition in the style sheet:

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

Example.

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

A:link           { color: red }   /* Unvisited links */
A:visited        { color: green } /* 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.

Example.

<xsl:template match="H4">
 <fo:block>
  <xsl:number level="any" from="H1" count="H2"/>
  <xsl:text>.</xsl:text>
  <xsl:number level="any" from="H2" count="H3"/>
  <xsl:text>.</xsl:text>
  <xsl:number level="any" from="H3" count="H4"/>
  <xsl:text> </xsl:text>
  <xsl:apply-templates/>
 </fo:block>
</xsl:template>

End example.

3.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].

3.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 (e.g., audio, animations), they have to allow users to turn off scripts, to stop animations, and to adjust timing parameters. Some user agents also allow users to turn off scripts for security reasons.

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:

Applet techniques

When a user agent loads an Java 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.

3.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. Some examples include:

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.

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:

Refer to the section on restricted functionality and conformance in UAAG 1.0 for more information about limitations in functionality due to content.

3.13 Synthesized speech techniques

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

References:

3.14 Techniques for reducing dependency on spatial interactions

Users with serial access to content or who navigate sequentially to content may have difficulty interacting with content in two-dimensional space (e.g., to move a pointing device). Using the keyboard to move the pointing device may help some users, but this technique usually requires a significant amount of visual feedback as well as physical dexterity, both of which may not be possible for users with some disabilities.

To illustrate ways to reduce dependency on spatial interactions, consider a Web site for travel through Europe. The author provides a map of Europe and allows users to select regions they wish to visit using a pointing device. This type of application is very convenient to some users, but may be inaccessible to others. Authors can design such content to place the emphasis on objects (in this case European countries) rather than screen coordinates. In HTML, for example, authors should use client-side image maps instead of server-side image maps.

When this is done, the user agent can present the list of countries in an alternative fashion (e.g., as a list of links or menu entries) for users who may find it difficult to select countries with the pointing device. This type of interface generally benefits all users (e.g., some users who may not recognize countries by shape or flag, some users may prefer the keyboard, some users may have images turned off, and the text may be searched).

3.15 Accessibility and internationalization techniques

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

For more information about content internationalization, refer to W3C's "Character Model for the World Wide Web" [CHARMOD] and the Unicode Consortium's Unicode specification [UNICODE].

3.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 W3C's "How People with Disabilities Use the Web" [PWD-USE-WEB].

learning
4.4
hard of hearing
1.3, 2.2, 2.5, 2.6, 4.1, 4.2, 4.3, 4.7, 4.12
memory
9.4, 9.10, 10.4, 10.5, 11.1, 11.2, 11.3, 11.4, 11.5, 11.6, 11.7
color deficiency
3.1, 4.3, 10.2, 10.3, 10.6
low vision
2.2, 2.5, 2.7, 2.8, 2.9, 3.2, 3.3, 3.5, 4.1, 4.2, 4.4, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12, 4.13, 5.1, 5.4, 9.1, 9.2, 9.3, 9.4, 9.7, 9.8, 9.10, 10.2, 10.3, 10.4, 10.5, 10.6
seizure disorder
3.3, 3.4
physical
1.1, 1.2, 2.4, 2.9, 2.10, 5.3, 5.5, 9.1, 9.2, 9.3, 9.4, 9.5, 9.6, 9.7, 9.8, 9.9, 9.10, 10.3, 10.4, 10.5, 11.1, 11.2, 11.3, 11.4, 11.5, 11.6, 11.7
all
2.1, 2.3, 4.14, 6.1, 6.2, 6.3, 6.4, 6.5, 6.6, 6.7, 6.8, 6.9, 6.10, 7.1, 7.2, 7.3, 7.4, 8.1, 8.2, 12.1, 12.2, 12.3, 12.4, 12.5
deafness
1.3, 2.2, 2.5, 2.6, 4.1, 4.2, 4.3, 4.6
cognitive
2.6, 3.1, 3.2, 3.3, 3.5, 3.6, 4.2, 4.3, 4.4, 4.5, 4.6, 5.1, 5.2, 5.3, 5.4, 5.5, 9.4, 9.8, 9.10, 10.4, 10.5, 10.7, 11.1, 11.2, 11.3, 11.4, 11.5, 11.6, 11.7
blindness
1.1, 1.2, 1.3, 2.2, 2.4, 2.5, 2.7, 2.8, 2.9, 2.10, 3.2, 3.3, 3.5, 4.4, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12, 4.13, 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.2, 10.3, 10.4, 10.5, 10.6, 10.7, 11.1, 11.2, 11.3, 11.5, 11.6, 11.7

3.17 Appendix: Accessibility features of some operating systems

Several operating systems include built-in accessibility features designed to assist individuals with disabilities. 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 common to several operating environments:

StickyKeys
StickyKeys allows users who have difficulties with pressing several keys simultaneously to press and release in sequence each key of the configuration.
MouseKeys
These allow users to move the mouse cursor and activate the mouse button(s) from the keyboard.
RepeatKeys
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
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
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
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
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 completeness and future compatibility.

ShowSounds
ShowSounds are user settings or software switches that cause audio messages to be presented using both audio and graphics. Applications may use these switches as the basis of user preferences.
HighContrast
HighContrast sets fonts and colors designed to make the screen easier to read.
TimeOut
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 completeness and future compatibility.

SerialKeys
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., through a serial port or infra-red port) rather than or in conjunction with, the keyboard, mouse, and other conventional input devices and 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
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 or current focus). Magnifier can also invert colors within the magnification window.
Accessibility Wizard
The Accessibility Wizard is a setup tool to assist users with the configuration of operating environment accessibility features.

References:

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 operating system version).

Additional accessibility features available for the Macintosh OS:

CloseView
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 operating system.
SerialKeys
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 operating systems supporting XKB may require command line interaction.

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.

3.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.10). 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) or a browser helper object);
  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.

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 environments:

Here is an example entry for Java:

assistive_technologies=com.ibm.sns.svk.AccessEngine

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:

HKEY_LOCAL_MACHINE\Software\Accessibility\DOM 
    "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 awt.properties file for the presence of assistive technologies and loads them as shown in the following code example:

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 {
     Class.forName(atName).newInstance();
   } 
   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.

Example.

import java.awt.*;
import javax.accessibility.*;
import com.sun.java.accessibility.util.*;
import java.awt.event.FocusListener;

class AccessEngine implements FocusListener {
 public AccessEngine() {
   //Add the AccessEngine as a focus change listener
   SwingEventMonitor.addFocusListener((FocusListener)this);
 }

 public void focusGained(FocusEvent theEvent) {
   // get the component object source
   Object o = theEvent.getSource();
   // check to see if this is a dom 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 Internet Explorer, 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 spaces 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.

Example.

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

  /* 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);
        }
           pColl->Release();
        }
        pHTMLDocument2->Release();
        }
        lDisp->Release();
    }
    pDisp->Release();
      }
    }
  }
}   

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