音声ブラウザご使用の方向け: SKIP NAVI GOTO NAVI

Web Posted on: January 8, 1999


Image of accessdoor

[Open Door to Accessibility]
IBM's Self Voicing Kit Technology for Java: IBM's Solution to Bring Cross-Platform Accessibility to Mainstream Computing

© Copyright IBM Corporation, 1998

The most current version of the guidelines discussed in this presentation are maintained at:http://www.austin.ibm.com/sns/access.html

Richard S. Schwerdtfeger
Senior Software Engineer and Lead Architect
IBM Special Needs Systems
Austin, TX
e-mail: schwer@us.ibm.com
Web: http://www.austin.ibm.com/sns/rich.htm

Phillip D. Jenkins
Accessibility Program Manager
IBM Special Needs Systems
Austin, TX
e-mail:pjenkins@us.ibm.com
Web:

IBM is continuing its tradition of leading the industry in accessible solutions by focusing on the Java platform for accessibility. Java is the fastest growing computer language and application environment in the industry. Java is fast becoming a cornerstone of many company network computing strategies. The accessibility features in the Java Foundation Classestm (JFC Swing), the Accessibility APIs, and the underlying object-oriented architecture provide a foundation for an accessible strategy.

IBM has collaborated with Sun Microsystems tm to bring the Java Accessibility APIs and their implementation in JFC to the industry. IBM is also encouraging its own developers to exploit the Java accessibility technology in its own programming tools and software solutions. Furthermore, IBM is also working with other access technology vendors to encourage and support their technologies so that working solutions become available in the Javatm environment.

The evolution of requiring National Language Support and Year 2000 readiness is now part of accepted standards for software development. The technology is now here to make the evolutionary step for accessibility. IBM SNS now believes that this is possible through Java. Today the technology is available for mainstream developers to easily build accessible applications. There is no excuse to NOT build accessible solutions.


2.0 Assistive Technology and Mainstream Computing

It has been the belief of many in the IBM Special Needs Systems organization that assistive technology has always been ications and assistive technology solutions. To do this, we need a mechanism that can provide a mainstream opportunity for application developers, that requires the software developer to follow the IBM accessibility guidelines, and that also delivers a cross-platform assistive technology solution. That mechanism is the Self Voicing Kit (SVK).


3.0 IBM's Self Voicing Kit

The Self Voicing Kit (SVK) is being built as a vehicle to enable mainstream developers and assistive technology vendors to:

  • Add self voicing capability to their applications through a separate SVK add on
  • Write customized audio application extensions called Perks
  • Analyze their application to ensure accessibility through a built-in Java accessibility analysis tool
  • Provide a screen reader UI to their application
  • Reuse and extend their technology to come up with better accessible solutions
  • The Self Voicing Kit (SVK) is also being built as a vehicle to:
  • Enable disabled users to use a portable assistive technology
  • Let operating system-specific screen readers quickly add customizable support to Java applications

The new technology that makes this possible is IBM's new Access Engine (AE) technology for the Java platform. Figure 1 shows a simplified diagram of the SVK Access Engine architecture as it would appear to a person writing a Perk.

3.1 Access Engine Technology

One of the features of the Java Accessibility Utilities is the ability to load an assistive technology in the background while a Java application is running. This allows IBM's Access Engine to be launched in the background when a Java Virtual Machine is started.

The Access Engine can be considered an application extension manager for extensions that make use of information managed by the AE as well as utilities the AE provides through its toolkit. The application developer needs no prior knowledge of the AE's presence; however, the application must follow IBM guidelines for writing accessible Java applications.

Imag of SVK Access Engine Architecture

Figure 1. Simplified Diagram of the SVK Access Engine Architecture
Simplified Diagram of the SVK Accessibility Engine architecture as it would appear from a Perk author's perspective.D

3.1.1 The View

The Access Engine monitors the screen and maintains a cached representation of the user interface through its interaction with accessible components. This cached representation is called a "View" and it is sorted by logical text representation items. View items that are non-text items have a Unicode text item associated with them.

3.1.2 The Perkolator

The concept behind the Perkolator is to allow a developer to extend the user interface of an application without modifying it. To extend the user interface (UI), the AE provides a Toolkit class, written in Java, that allows you to gain access to features of the Access Engine. Examples of extending the UI include the ability to speak a message, read the text in a particular item, or read the role of the item. The amount you can extend the user interface depends on the capabilities the toolkit provides. In the future, we would like to extend the toolkit to perform tasks that improve the readability of documents, such as increasing the space between lines.

The Perkolator manages application extensions called Perks that are written in Java. Perks are an extension of the Access Engine toolkit and define a collection of Tasks that are registered to respond to an event or device command. For example, you might "register" a task in your Perk that the Perkolator activates when a focus change occurs or when the user presses a keyboard command sequence to speak the current line.

Each Task is a class that extends the Toolkit class like a Perk. The Toolkit handles the communication between the Perk and the Access Engine.

The Perkolator divides application extensions into stacks, called Tiers. There is a stack of Perks for a given running application. As the user switches between applications, the Perkolator swaps the Tier based on the foreground application. This enables a customized user interface for each foreground application. Furthermore, a developer can create and compile a new extension and dynamically add it to the current Tier.

3.1.3 Tiers

In the Perkolator, the Tier manager handles the Perk application stack. It manages the:

  • Perk application exceptions
  • Mapping of events to Perk tasks
  • Mapping of device key commands to Perk Tasks
  • Local Tier data

This concept is a derivative of what was developed for IBM Screen Reader/2, with the exception that Perks are written in Java. As a Perk developer, you can overload device commands in a new Perk and dynamically push them onto or pop them off of the Perk stack, creating a different user interface without changing the foreground task running.

3.1.4 Perks

Perks are a derivative of the Profile concept in IBM Screen Reader/2. In fact, many of the functions supported in the SVK toolkit are similar to those found in IBM Screen Reader/2. Perks, however, are much more powerful because they are written in Java. This enables:

  • Perk developers to write in a mainstream language
  • Perk developers to use the features of Java
  • Application developers to write their own Perks in a familiar language
  • Assistive Technology Vendors to build their own user interface
  • IBM to rapidly add new functions to the SVK without changing the Perk compiler
  • Figure 2 shows a sample Perk for IBM's phone directory Java program for IBM employees, called Blue Pages. This user interface extension is designed to expand the speaking of the number, to speak the digits individually as we would speak a phone number, and to register an automatically activated task that speaks the connection state when it changes.
----------
Figure 2: Sample Perk for IBM's Blue Pages import com.ibm.sns.srj.*;
public class BluePagesPerk extends Perk {
   public void init() {
      // so numbers read "better"
      setNumExpand(On);
      // to read the connection message when it changes
      registerAutoTask(new ConnectionWatch(), 2);
   } // BluePagesPerk#init
   // to read the connection message when it changes
   class ConnectionWatch extends AutoTask {
      String watchedString = "";
      public Object evaluate() {
         // Save all Settings of the Current Task, Will be Restored on Task Exit 
         save();         
         setTrap(Off);   // Turn verbal exception notification off.
         int count = getItemCount();    //Get the number of Items in the current View
         // If the View is valid and the next to last item is a Combo Box
         // Then set the latest object to evaluate to the ComboBox text
         if (count != 0) {              
            // the second to last item
            String text = getItemText(count-2);
            if (text != null) {
               if (getClassName(count-2).indexOf("ComboBox") != -1) {
                  watchedString = text;
               }
            }
         }
         return (Object)watchedString;
      } // 
BluePages.ConnectionWatch#evaluate
      //When the Object evaluated changes, in this 
      //case the combo box text, this method is triggerd 
      //by the access engine to say the Combo Box text. 
      public void execute(Object trigger) {
         msg( 
(String)trigger);
      } // BluePagesPerk.ConnectionWatch#execute
   } // BluePagesPerk.ConnectionWatch
} // class BluePagesPerk 
----------

3.1.5 Swappable Device I/O Technology

It is myopic to assume the only device that can control a Perk should be limited to the screen reader keypad or the keyboard. What if the user wanted to use an on screen keyboard, voice recognition, Braille device, or special keyboard such as Don Johnston's Discover? To solve this problem, the Access Engine supports pluggable Input and Output objects that can easily be extended for different devices, but do not require a rewrite of the AE to support them. The Perk developer merely has to register a command for a specific device to activate a particular task. Commands have string representations that are specific to a particular type of device. If a device is supplied, the user can rapidly swap the device and command string to an existing task that is currently mapped to a different device. Furthermore, the AE allows the user to install multiple devices to control the application extension.

3.1.6 Accessibility Test Tool

Until Java, it was not possible to have consistent cross-platform guidelines for making accessible applications. The Java Accessibility API and its Swing/JFC implementation remove the need for an Off Screen Model (OSM). This fact has enabled IBM to write concrete guidelines about how to write accessible applications. These guidelines, called the "IBM Guidelines for Writing Accessible Applications Using 100% Pure Java", are readily available for free from the IBM Special Needs Web site.

The availability of the Java Accessibility API and its Swing implementation has enabled us to build an accessibility test tool into the SVK as a component that can be activated during normal AE operation. This is an industry first. Best of all, it runs, "as is", on multiple operating system platforms. At the time this paper was authored, this tool was still in development. Of its many features, it runs a complete tree view component analysis of your application to ensure it follows:

  • Java Accessibility Guidelines
  • Keyboard Accessibility Guidelines, including those involving usability

If developers want to use the SVK, their applications must be accessible. The incorporation of an accessibility test tool with an assistive technology is another industry first.

3.2 Demonstration of SVK Technology

At this presentation, IBM Special Needs Systems will demonstrate the SVK running on multiple platforms with various applications. The number of platforms, such as Windows tm, Solaris tm, etc., and applications, such as Bobby tm, BluePages tm, etc., demonstrated depend on what is tested between now and the conference.


4.0 IBM's Java Accessibility Strategy for 1999

4.1 Collaboration with Sun

Due to the success of our Java accessibility collaboration, IBM and Sun are continuing their collaboration to work on the new Java Accessibility API extensions: AccessibleDocument and AccessibleTable. The extensions will increase the ease-of-use of complex documents and tables with specific attention to persons with reading disorders. Additionally, IBM and Sun are collaborating on enhancing the accessibility features in JavaOStm for Businesstm.


4.2 SVK

Java continues to be IBM's strategic focal point for next-generation accessibility. IBM's vehicle for Java accessibility acceptance is the Self Voicing Kit. Early beta tests of the SVK by the National Security Agency and the IBM Blue Pages development team have been very promising. Furthermore, groups like CAST and IBM Blue Pages development have provided valuable feedback to improve the completeness of the "IBM Guidelines for Writing Accessible Applications Using 100% Pure Java". In 1999, IBM's plans are to:

  • Expand the SVK beta test program
  • Continue to enhance the SVK
  • Work to incorporate the SVK into mainstream solutions
  • Work with native Assistive Technology Vendors
  • Evangelize the SVK and Java accessibility technology
  • Work to extend the SVK for advanced assistive technology solutions

5.0 Appendix

5.1 Trademarks

IBM©, OS/2©, AS/400©, Screen Reader/2©, and VisualAge© are trademarks or registered trademarks of International Business Machines Corporation in the United States and/or other countries.

Microsoft©, Windows©, Windows95©, and WindowsNT© are registered trademarks of Microsoft Corporation.

Sun Microsystemstm, Javatm, 100%Pure Javatm, Java Foundation Classestm, Swingtm, Solaristm, JavaOStm, and JavaOS for Businesstm, are trademarks of Sun Microsystems Inc.

Other company, product, and service names may be trademarks or service marks of others.


5.2 Notices

THIS DOCUMENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

All statements regarding future intent are subject to change or withdrawal without notice and represent goals and objectives only.

Information in this document about non-IBM products was obtained from the suppliers of these products, published announcement material, or other publicly available sources.

The information contained in this document represents the current views of IBM on the issues discussed as of date of publication. IBM cannot guarantee the accuracy of any information after the date of publication.

© Copyright IBM Corporation, 1998