| I l@ve RuBoard |
|
25.1 How Accessibility WorksAssistive technologies are a feature of Java. These technologies typically manifest themselves as a class archive, such as a JAR file, that resides separately on the user's local machine. As we mentioned earlier, however, Java offers assistive technologies a wide latitude of control over an application for two reasons:
Let's take a look at an accessibility-enabled Java virtual machine (JVM). When a JVM is started, it searches a configuration file for a list of specialized classes (we'll provide specifics about this later in this chapter). If it finds them, it loads the classes into the same namespace as the application that it is about to execute. Thus, when the Java application starts, the assistive technologies start with it. The second important step is replacing the GUI event queue with an appropriate queue for the assistive technology. Hence, the application, GUI event queue, and assistive technology work together to make accessibility possible. Figure 25-1 shows how an assistive technology interfaces with the JVM. Figure 25-1. An assistive technology in the JVM 25.1.1 Evolving Accessibility SupportBefore we get started, it's important to say that the accessibility features and even the approach to accessibility varies a bit depending on the version of Java you're using. The next few sections briefly describe the main differences you should be aware of; other differences are noted throughout the chapter. 25.1.1.1 Version 1.1 accessibilityA 1.1 JVM searches the awt.properties configuration file for a list of specialized accessibility classes and, if they are there, loads them before starting up. Here's a segment of the awt.properties file with the appropriate additions for JDK 1.1 accessibility highlighted in bold: AWT.alt=Alt AWT.meta=Meta # Assistive technologies AWT.assistive_technologies=SpeechRecognition AWT.EventQueueClass=com.sun.java.accessibility.util.EventQueueMonitor # Key names AWT.enter=Enter AWT.backSpace=Backspace There are two important lines in the "Assistive technologies" section of this file. The line beginning AWT.assistive_technologies= refers to a class on the current CLASSPATH where Java can find an assistive technology. Each time the user starts the virtual machine, the assistive technology class is instantiated as well. The other line, AWT.EventQueueClass=, refers to an Accessibility Utility API class that aids accessibility by replacing the Java graphical event queue. (We will talk about this class later in the chapter.) 25.1.1.2 Version 1.2 accessibilityIn 1.2 and beyond, the virtual machine loads a different file: accessibility.properties in the jre/lib directory. Whereas 1.1 required specifying the AWTEventQueue property explicitly, 1.2 and later handle this automatically. However, you still need to specify which assistive technologies should be loaded into the JVM at startup. Hence, the very brief accessibility.properties file for JDK 1.2 and later might look like this: # Assistive technologies: only one line assistive_technologies=SpeechRecognition 25.1.1.3 Version 1.3 accessibilityIn addition to following the approach introduced in 1.2, SDK 1.3 added several classes and interfaces, including:
The other major change in 1.3 concerns the location of the low-level accessibility support code. In the 1.3 release, that code moved into the java.awt.Component and java.awt.Container classes, making it possible to use the same framework for lightweight AWT components. As an interesting side note, Version 1.3 also added the java.awt.Robot class. While not specifically part of Swing or Accessibility, the Robot class allows for things such as screen captures and "mouse warping" (moving the mouse programmatically). If you intend to support assistive technologies such as screen magnification, this class is invaluable. 25.1.1.4 Version 1.4 accessibilityImprovements in accessibility support continue to evolve in subsequent Java versions; they build on the changes in 1.2 and 1.3 noted above. SDK 1.4 includes a few new classes and interfaces:
Several other constants and properties were added, mostly to make it easier for developers to understand the assistive technologies in a given environment. For example, the javax.accessibility.assistive_technologies system property allows you to specify the assistive technologies to load at runtime. Two boolean properties, javax.accessibility.screen_reader_present and javax.accessibility.screen_magnifier_present, provide indications that particular technologies are installed and available on a system. While it is always a good idea to develop applications that are compatible with such technologies, developers who want to be extra careful on systems with these features can now do so. One of the most welcome category of changes in the 1.4 release relates to navigation through and interactions with HTML pages. Support for <object> tags and keyboard link traversal are among the more notable additions. 25.1.2 The Accessibility ContractIn theory, accessibility defines a "contract" between an application and an assistive technology. The contract goes like this: in exchange for providing an alternate interface that allows users greater power to interact with my application, I will allow outside control of many or all of my components. With Swing, you do this by activating accessibility properties and interfaces inside your components. If you stick to the Swing components in your application, this is a trivial task—it's already done for you. However, if you're using AWT, it can be more difficult. Let's take a look at the fine print:
Note the last point. This allows the assistive technology to be able to "sniff" various GUI events at the system level and react accordingly. For example, if focus shifts from one application to another, a voice-recognition assistive technology can monitor that change to switch to a vocabulary appropriate for the new application. 25.1.3 How Do I Get It?The exact procedure for implementing accessibility features depends on whether you are making a Swing application or an AWT application accessible. 25.1.3.1 SwingIf you are using Swing components in your application, then almost everything is taken care of for you. You need to do only two things to make your components accessibility-friendly: provide an accessible name and provide an accessible description for each component. In certain cases, these properties may be set for you automatically. If not, both are trivial additions, as shown below: JTextField text = new JTextField( );
text.getAccessibleContext( ).setAccessibleName("Name");
text.getAccessibleContext( ).setAccessibleDescription("Enter A Name");
By having these two properties set in your components, any assistive technology that has been loaded into the JVM can successfully query the component to determine how it can best be used. As we mentioned, these properties are often derived from other common attributes of the Swing components, such as labels and tooltips. The following has the same effect as the code we just showed: JTextField text = new JTextField( );
JLabel label = new JLabel("Name");
label.setLabelFor(text); // Sets text's accessibleName
text.setToolTipText("Enter a name"); // Sets text's accessibleDescription
25.1.3.2 AWTSDK 1.3 added accessibility support to the Component and Container classes. While we heartily encourage you to write applications with Swing components, any applications that require AWT components can still be made accessible. In general, if you are curious about the state of the accessibility package, check out http://java.sun.com/products/jfc/accessibility.html. From there you can link to all the latest additions and several good overviews of the goals (and the details) of javax.accessibility. (The accessibility tools have their own version numbers, so don't be alarmed if the latest version you see is a 1.3 release—that doesn't mean it won't work with the latest release of the Java 2 SDK.)  |
| I l@ve RuBoard |
|