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

Web Posted on: November 24, 2998


Java Accessibility : A Primer on the Java Platform and Java Accessibility

Earl Johnson
Peter Korn
William Walker
Sun Microsystems, Inc.
901 San Antonio Rd.
Palo Alto, CA 94303
access@sun.com

Introduction

Java computing is rapidly being embraced by industry and education alike. For example over 400 colleges and universities are teaching the Java language as a beginning computer programming course. On the corporate front a recent corporation focused survey found that in the coming year 84% of them will be developing new applications in Java 75% of them will use Java to extend the life of their legacy applications. This rapid embracement is further indicated by the latest numbers for Java programmers showing over 700,000, the fact that the Java phenomena is 3.5 years old at this writing, and over 1,000 different books have been written about the technology.

Still, what we are seeing is people with disabilities are only just now starting to be exposed to and affected by Java technologies in a significant way. It is this growing exposure that is driving further investigation into what the Java platform can do and, more importantly, into what type of accessibility support has been built into the platform. This paper was written to help provide some information in these areas. Specifically, this paper gives a high level overview of the Java platform, talks about the GUI components in the Java Foundation Classes and the accessibility support they provide, identifies the broader aspects of Java Accessibility, and quickly touches on future issues.


The Java platform

Java technology's product possibilities and realities cover a broad range of user environments. Java applets and applications (app/lets) run on platforms that include traditional desktop computers such as X Windows, Windows, and Macintosh, on future JavaOS generations of networked computers, on copying machines, on public systems such as information kiosks and automatic teller machines, and on home based products like set-top boxes and environmental control systems.

People are excited about the Java platform because it allows software engineers to "Write Once, Run Anywhere" (SM) -- that is to develop a single version of an application that can be used on a variety of computers and devices. This means that users will see better integration occurring between their desktop work systems, intermittently connected work systems, PDAs, and ATM. Large companies, independent software vendors (ISVs), and government agencies benefit also because they will be able to consolidate the groups of software engineers working on applications for different platforms into one group working on Java app/lets that run on any of these same platforms.

The Java platform is at the heart of this capability and is comprised of two main components - the Java Virtual Machine (JVM) and the Java Application Programming Interface (Java API). The JVM can be thought of as the translator and facilitator of communication between Java app/lets and the native platform the Java platform is running on while the Java API is the set of tools and components with which to build portable app/lets with. It sits on top of other platforms (e.g. CDE, Macintosh, Windows), and compiles to bytecodes, which are not specific to any physical machine, but are machine instructions for a virtual machine. The bytecode is read by the JVM and translated into a format the native platform understands, this capability is what enables the Java platform's cross native platform portability.

The Java APIs, the other half of the Java platform, are a set of packages of software components that provide a wide range of functionality from which to build robust applications with. The core API is the API included in every full implementation of the Java platform. The core API provides support for input and output, data structures, system properties, date and time, internationalization, networking, user interface components, applets, and more. The Java API set can also be extended through standard extensions from which some get promoted to core. The Swing components and Java Accessibility are two such examples.

The following figure depicts a Java program, such as an application or applet, that's running on the Java platform. As the figure shows, the Java API and Virtual Machine insulates the Java program from hardware dependencies.

block diagram showing Java program using Java platform to gain platform independance

Not all the above technologies will play an active role in enabling accessibility on the Java platform. Technologies that do play a role in supporting accessibility are Java Foundation Classes (JFC), Java Accessibility API and Utilities, Abstract Window Toolkit (AWT), JavaBeans, JavaSpeech, Java Native Interface>/a> (JNI), Remote Method Invocation (RMI), Reflection mechanism, JavaOS. More on the JFC and Java Accessibility API an! d Utilities follows.

Last but not least is the Java Language which acts as the on-ramp to all the power provided by the Java platform. Some highlights of the language are it is simple, yet flexible and powerful, that is object-oriented (with single inheritance), statically typed, multithreaded, dynamically linked, and has automatic garbage collection. Its syntax is based on C and C++, so those programmers can pick it up quite easily. Finally its strong data typing, automatic garbage collection, array bounds checking, lack of automatic type coercion, and the lack of the pointer data type encourages catching bugs early, during development.


The Java Foundation Classes user interface components (Swing)

Swing extends the original Abstract Windowing Toolkit (AWT) by adding a rich set of graphical user interface components that are completely portable and delivered as part of the Java platform. Examples of components include push button, menubar, text pane, and table. Application Developers are attracted to Swing because its comprehensive set of graphical user interface (GUI) components and foundation services greatly simplifies the development and deployment of 100% Pure Java (TM) applications for the Internet, intranet and desktop environments. By being 100% pure developers get by a big limitation of the AWT which relies on user-interface code that's native to whatever operating system they're running on. If one native platform's GUI toolkit didn't support a component, e.g. a tabbed pane, then the AWT couldn't support it. Doing so would break the AWT's cross platform capabilities. With its Pluggable Look and Feel Swing also allows developers to create applications that reflec! ts the operating system on which it runs, or use the GUI components to create their own platform-independent interface. Examples include an audio based user interface and the new Java look and feel that ships with Swing.

Swing also excels on the accessibility support front. For the first time accessibility has informed the design of and been built into a commercial UI toolkit. Mouseless or keyboard navigation support is already implemented on interactive components. The Pluggable Look and ccessibility API. Utility tools are also necessary in order to provide the necessary support for assistive technologies to locate and query user interface objects inside a Java application running in a Java Virtual Machine. These tools also provides support for installing "event listeners" into these objects, event tracking, and support for loading assistive technologies into the Java Virtual Machine. Finally, example tools are provided with the package that highlight how to enable assistive technologies to interact with the Accessibility API support built into Swing components. All these tools are provided in the Java Utilities package.


The Java Accessibility Bridge

Java applications run on a wide variety of host operating systems, many of which already have assistive technologies available for them (e.g. Macintosh, OS/2, Microsoft Windows). In order for these existing assistive technologies to provide access to Java applications, they need a bridge between themselves in their native environment(s), and the Java Accessibility support that is available from within the Java Virtual Machine (JVM). This bridge, by virtue of the fact that it has one end in the JVM and the other on the native platform, provides this pathway. Sun is currently developing a bridge for the Win32 platform in cooperation with assistive technology vendors and the various platform vendors.


The Pluggable Look and Feel of the Java Foundation Classes

The JFC is a set of user-interface building blocks that separate the state and model of information from the presentation of that information. Programs built with the JFC are not tied to a specific representation of their information (e.g., a specific list box, menu bar, or push button), but can instead allow its presentation to be programmatically determined, and can be chosen by the user. This is exciting because users will no longer need an interpretive assistive technology, a screen reader for example, but instead may purchase and specify in his or her configuration a set of audio- or tactile-based presentation tools instead of or along with a generic or customized visual presentation. So when a JFC-based program runs on this user's system and their system is configured correctly, information will be presented via one or more of these alternate modality channels. In this fashion, we have hope that the Pluggable Look and Feel will, for the first time, enable direct accessibility in mainstream applications providing.


Java Accessibility, the Bigger Picture

This paper has discussed the successes to date in building accessibility support directly into components used to build user interfaces, getting information about this out to the broader developer community, and enabling an architecture that can support choice in how users interact with and are presented information. For the most part however these are related to efforts that are primarily architecture based. Experience shows us though that true access takes much more than architectural support. This section enumerates many of the additional steps necessary to enable a broadly accessible digital world and provides some status updates on Sun's and other's work. We welcome your comments on entries we missed, please send them to us at access@sun.com.

  • An Accessibility API and underlying architecture that supports communication and object interaction between assistive technologies and applications or enables a person to directly access information without the need of a special assistive technology.
  • Status: Implemented on Swing and discussed above
  • Documentation on the underlying accessibility support broadly documented in general programming books.
  • Status: Most JFC programming books provide this coverage
  • Accessible design and testing tips included in Interface Design and Programming guideline texts books.
  • Status: IBM has made an excellent start with their set of publicly available guidelines
  • Assistive Technology Vendors who provide technical review and input on then develop products that are compatible with the Accessibility API.
  • Commercial and internal ISVs in all categories who utilize the guidelines mentioned above to help establish then meet accessible design criteria, develop these products utilizing the development tools covered in the next bullet where possible and practical, then establish an improvement roadmap where applicable.
  • Developer tools that support the Accessibility API in the UI and development environment, expose the properties associated with the Accessibility API to developers, and provide accessibility lint type features that perform basic accessibility evaluations of the app/let in design.
  • On-line information and help in applications and on the web that is written in accessible formats.
  • Customer service and field representatives who are familiar with the accessibility support in their products, know what compatible assistive technologies are available, understand how the state of current legislation and accessible products that are available can be factored into aiding sales, and can help customers fulfill their accessibility needs.
  • Most importantly customers who demand products that support, promote, and enable accessibility - companies do respond to customer demand, especially when big bucks are involved. This would include: agencies, education, and corporations setting contract requirements for accessible technology in new contracts, internal employees in these organizations who represent the concerns of employees with disabilities tracking and influencing new purchases and working with and pressuring internal development groups to develop accessible internal applications, individuals joining advocacy groups whose charter includes tracking the state of accessibility in products and applying pressure on manufacturers as required, and employees and students actively tracking and influencing decisions that result in the choice or development of applications crucial to the successful completion of their work.

Looking Ahead

As suggested early in the above Java platform discussion it is designed to power much more than desktop systems. Still, most of this discussion has dealt primarily with the development efforts that pertain to access to desktop types of systems (PC, laptop, etc.). The Java platform also powers consumer electronic devices like set top boxes, smart phones, and more - these are powered by the Personal and Embedded portions of the Java platform.

Sun has recently begun looking into interaction requirements for categories of consumer devices. The goal is to determine what an underlying architecture for these devices must provide to enable accessibility in products. While there is still much to do, some requirements have bubbled up already. The reality we found was these devices each have common as well as unique accessible interaction requirements associated with them. Many devices also have very tight memory constraints which means if a technology isn't deemed needed, it isn't included. And unlike desktop systems, some of these devices will be targeted to specific consumer groups or interaction environments which may not be practical for use by some major disability types. These are difficult design challenges to account for - that being the design an architecture in components that can expand to provide desktop like accessibility support as perhaps a set top box requires -and- contract to nearly nothing in a small dev! ice whose interaction modality simply can't or won't be expanded to