 |
 |
 |
|
|
|
| What are Java? | Presented by: |  Copyright 2000© |
|
|
Contents:
Java[tm] technologies are rapidly being embraced by industry and academia alike. According to the Sun Developer Relations (SDR) group, over 1000 colleges and universities worldwide now offer courses in the Java programming language. On the corporate front, a recent Zona Research survey found that in the coming year 84% of corporations will be developing new Java-based applications. In 75% of these cases, this development is being done to extend the lives of aplications running in legacy environments. This widespread adoption of the Java Platform is also evident when the number of Java programmers (over 700 thousand) and the number of books that have been written about the Java language (over 1200) are considered. Even more impressive, is the fact that the Java phenomenon is only three and a half years old.
And yet, people with disabilities are only just starting to be exposed to and effected 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 it.
The Java programming language was developed as a small-footprint object- oriented programming language. It was loosely based on C++, but was designed to be processor-independent and network savvy.
The work that resulted in the invention of the Java Platform was focused on producing an interactive computer-television system that enabled the functionality provided in today's set top boxes--email, web browsing, TV programming, and more. It originally encompassed both hardware and software aspects but soon became a software-focused development effort. Taking a page from UNIX's early days, Sun freely released the Java language and platform to get design input and to promote early visibility with developers. The resulting interest and feedback exceeded all expectation, and led to the open design process that is still followed and required for all methods of technology design at Sun.
Java technology's product possibilities and realities cover a broad range of user environments. Java applets and applications run on platforms that include traditional desktop computers, future JavaOS[tm] generations of networked computers, public terminals, and home-based products. Traditional desktop computers use platforms such as X Windows, Microsoft Windows, and Macintosh; public terminals are things like information kiosks and automatic teller machines (ATMs); and home-based products refer to set-top boxes and environmental control systems, and other personal networks.
People are excited about the Java platform because it allows software engineers to "Write Once, Run Anywhere"[tm] - 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, personal data assistants (PDAs), and public terminals like ATMs. In this way, large companies, independent software vendors (ISVs), and government agencies benefit because they are able to consolidate the groups of software engineers working on applications for different platforms into one group that is focused on the development of Java applets and applications that will run on any platform.
The Java platform is comprised of two main entities. These are the Java Virtual Machine (JVM) and the Java Application Programming Interface (API). The JVM is the translator and facilitator of communication between Java applets and applications, and the native environment that the Java Platform is running on. The Java API is the set of tools and components with which to build portable applets and applications.
Figure 1 depicts a Java program, such as an application or applet, that is running on the Java platform. The Java API and the Java Virtual Machine insulate the Java program from hardware dependencies.
Figure 1: Java program using Java platform to gain platform independence.
Figure 2 provides a block diagram illustrating how the cross-platform capability is enabled.
Figure 2: The flow of platform-independent Java code between different platforms.
The Java APIs, the other half of the Java
platform, are a set of software component packages that provide a wide
range of functionality with which to build robust applications. A core
API set is included in every full implementation of the Java
platform. Some of the functionality provided by the core API set
includes:
Not all of the technologies mentioned above will play an active role in enabling accessibility on the Java TM Platform. The following are brief descriptions of specific technologies that make accessible product design possible.
Last, but not least, is the Java Language which acts as the on-ramp to all the power provided by the Java platform. The Java language is simple, yet flexible and powerful; object-oriented (with single inheritance); statically typed, multithreaded, and dynamically linked. Its syntax is based on C and C++, so that those programmers can learn it 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 the development cycle.
Swing extends the original Abstract Windowing Toolkit (AWT) by adding a rich set of graphical user interface (GUI) 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 these GUI components and foundation services greatly simplify the development and deployment of 100% Pure Java[tm] applications for the Internet, intranet and desktop environments. By being 100% Pure, developers get around a big limitation of the AWT that relies on user-interface code that's native to whatever operating system they're running on. If one native platform's GUI toolkit doesn't support a component, e.g., a tabbed pane, then the AWT wouldn't support it. Doing so would break the AWT's cross-platform capabilities.
With its Pluggable Look and Feel (PLAF), Swing also allows developers to create applications that reflects 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 the Java Development Kit.
Swing excels on the accessibility support front. For the first time, accessibility has informed the design of and been built into a commercial UI toolkit. The Accessibility team worked closely with the Swing team to help design accessibility into the toolkit, to contributed code to the development effort, and to fix accessibility problems in components that were uncovered by the developer community at large. The team also built the Java Accessibility API directly into its user-interface components. As a consequence, the Accessibility API is covered in nearly all of the programming guideline books published on the Java Foundation Classes. Further information on the API is provided in the next section.
Another industry-leading feature is Swing's PLAF architecture. The pluggable look-and-feel raises the bar in a new way. Today's assistive technologies, such as screen readers and screen magnifiers, are essentially interpreters of information presented in pre-determined formats. The ideal would be to provide architectural support into the GUI components such that the user could choose the manner in which information was presented to them. For example, an audio instead of, or in addition to, a visual display. Swing's PLAF architecture takes a significant step towards enabling this future vision of product accessibility - direct access without the need of an adjunct assistive technology. Further information on the PLAF is provided in the next section.
Mouseless interaction, like a built-in Accessibility API, is another key requirement of users with disabilities. All interactive Swing components have keyboard navigation support already implemented on them, making it even easier for developers to build accessible applets and applications. The keybindings are look-and-feel dependent and, in the case of Windows and CDE, are based on the specifications provided by the interface design guidelines associated with these platforms. The specific keybindings can be obtained in the javadoc entries for each component.
The work described below comes from several sources: an in-depth review of accessibility requirements for the Java platform as specified in an evaluation and report commissioned by Sun in March, 1996; a 3-day meeting hosted by Sun in February, 1997; the expertise and background knowledge of the members of the Sun Accessibility team; and the ongoing feedback from IBM, Trace Research, the University of Toronto, assistive technology vendors, and the larger disability community. The following four sections provide a brief overview of this work.
The Java Accessibility API defines a contract between the individual user interface components that make up a Java application and an assistive technology that provides access to that Java application. If a Java application fully supports the Java Accessibility API, then it should be compatible with, and friendly toward, assistive technologies such as screen readers, screen magnifiers, etc. With a Java application that fully supports the Java Accessibility API, all text is fully exposed so no off-screen model is necessary. Also, while the API is built into and helped inform the design of the Swing components, it was designed to be both toolkit independent and extendable. This means it can readily account for new types of, or custom, components as well as be implemented on other toolkits.
In order to provide access to Java applications, an assistive technology requires more than the Java Accessibility 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 provide 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.
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 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 PLAF will, for the first time, enable direct accessibility in mainstream applications providing.
Consider this scenario. Three strangers from three companies--on the road to jointly bid a job. Among them they have a laptop, a project disk drive with data & applications, a PDA, a cell phone, and a clamshell pager--and their presentation is not ready. Their hotel suite has a small network: scattered net jacks, a couple of infrared & short-range RF transceivers, and though they never worked together before, they have snapped into an impromptu working community. The suite has an Internet gateway & low-resolution printer. The TV, the VCR, and the set-top box are connected to the same network. As they work they use all the services in the room, including those on each other's devices. Plug in the disk & PDA, turn on the laptop & TV--total setup time: 2 minutes.While one of them edits the presentation, the others watch it unfold, mirrored on the TV. From time to time one of them takes the laptop to another hotel room to concentrate on a section while the others keep working, running simulations from the project disk on the gateway & viewing results on the TV. Sometimes one of them prints a slide or graph to proof. With the clamshell they fetch files from offices & email questions. Using the cell phone as a remote, they order room service through the TV & check their flights.
When they're done, they need a high-resolution set of overheads. From the pager they reserve the hotel's high-res color printer for 15 minutes--it's in a small room down the hall. Using the suite key programmed by the reservation service to open the room, one of them goes into the printer room, loads foils bought from online room service, and phones into the suite's network to start printing.
Introducing accessibility into this scenario, any one of the collaborators in it could be someone with a disability but that would not matter because they would be collaborating using their own accessible smart device. This could be a laptop, PDA, or some other portable notetaker. Think the above does not apply to you? Instead, imagine a scenario where a public building has a Jini compliant directory system that gives you directions and guides you to your destination through your own personal smart device which also happens to be the same device you use at home to control your stereo, TV, thermostat, ... Or perhaps you need to use an Information Kiosk but are a quadrepeligic. Jini enables your laptop to interact with the kiosk and check on the availability of your favorite book or what your favorite store's hot sales are...
Jini is a complimentary part of a strategy where the Java platform (through the JFC), provides support that allows someone to physically interact with a device such as a Kiosk while Jini enables access to the same device to someone who can't physically use it by external means.
So far, 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 that true access takes much more than architectural support. This section enumerates several additional steps necessary to enable a broadly accessible digital world and provides 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.
The Java platform is designed to power much more than desktop systems. Most of this paper has dealt primarily with the development efforts that pertain to access to desktop types of systems (e.g., PC, laptop, etc.). But, the Java platform also powers consumer electronic devices, such as set top boxes and smart phones, which are powered by the Personal and Embedded portions of the Java platform as well as Jini Technology.
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 Sun found was that 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 device whose interaction modality simply can't or won't be expanded to account for one or more types of disabilities.
We have made much headway in making the Java platform enable, support, and promote accessible design. The accessibility API and pluggable look-and-feel set new standards in platform access, and we have desktop-related refinements to this work we want to add in future releases to make the platform even better.
There is much work remaining in getting accessibility support fully enabled in end-user applications and building accessibility support into the architecture used in consumer devices. You, too, have work to do if you want to enable the Java applications you will soon be using to be accessible. You need to speak up so application developers and assistive technology vendors hear you and take the call seriously.
|
Home
| Search
| About |
Offices
| Manufacturers |
Products
| Services |
Ordering |
| Copyright© 2008 [Pulse, Inc.]. All rights reserved. Tel: (toll free): 888-785-7393 Int'l: 1-951-694-1173 Fax: 1-951-694-1173 Sales: sales |
