There are several ways that ATs can be realized. They differ in two important points. The first one is how the AT represents the information it obtains from OpenOffice.org and presents it to the user. The second difference is how ATs obtain this information in the first place.
In its simplest form, the communication between AT and OpenOffice.org involves only the accessibility API and, where necessary, some additional features from other parts of the UNO API. Existing ATs, however, do not know anything yet about the accessibility API. They use one of several ways to access OpenOffice.org by using one or more bridges that translate between different APIs:
- The UNO access bridge translates between the accessibility API and the Java Accessibility API. Note that this is not the same as the Java version of the accessibility API.
- The Windows/Java access bridge translates between the Java and the C versions of the Java Accessibility API.
- The Gnome access bridge translates between the accessibility API and the Gnome Accessibility API.
In order to make OpenOffice.org accessible, it is necessary to support the accessibility API. The characteristics of the bridges have to be taken into account as well.
Under Windows, OpenOffice.org itself has a switch that can turn on or off the accessibility support. This switch can be reached through Tools – Options – Accessibility. Under Linux and Solaris, an equivalent setting can be made in the Gnome environment. When accessibility is activated, on every launch OpenOffice.org will start its own Java VM, which in turn starts all registered AT tools. This will be explained in the next section.
|Content on this page is licensed under the Public Documentation License (PDL).|