Accessibility
Architecture Of An Automatic Teller Machine Usable By All Using The Java PlatformPeter Korn, Sun Microsystems, Inc.This paper discusses the architecture of a Universally Accessible Automatic Teller Machine (ATM) prototype, designed by Sun Microsystems for the Java Platform. An ATM machine is of the more complex types of kiosks that must be able to interact with anyone who approaches it - where "anyone" includes people who speak different languages, people who may have one or more disabilities, and people who have different levels of expertise and comfort with information technology. The Universally Accessible ATM prototype is a proof-of-concept demonstration which illustrates how the technologies available in the Java platform can be used to create an ATM machine that automatically re-configures its user interface to match the needs of the user. Contents:
BackgroundIncreasingly kiosks are being used by companies to provide public interfaces to information. These include information kiosks in universities and colleges, large office buildings, convention centers, and malls; transit information kiosks at bus and train stations and at airports; kiosks for use in voting; and of course ATM machines. In virtually all of these situations, the companies that install the kiosks serve a public that includes people with disabilities. In many of these situations, kiosks serve people whose native language may not be that of the country where the kiosk is - especially for information kiosks in airports where there are many tourists. To accommodate a user with disabilities, and to support users in their own language, it is very important (and in some cases legally mandated) that kiosks have the ability to conform to the users specific needs. User PopulationsIn the increasingly global and multi-lingual world that we live in, individual users of kiosks and ATM machines may not speak the language of the host country that the kiosk resides in. Immigrants from foreign countries, as well as business travelers, find themselves in front of kiosk machines they cannot use because they don't speak the language of the kiosk. Users who have low vision or are blind often find themselves in front of kiosks they cannot see. Users with physical impairments often find themselves in front of kiosks that use inaccessible touch screens. In the United States there are almost 8 million people who have a disability so severe they cannot use a computer without some form of assistive technology. Far larger is the population of users who are over 65 years old and would greatly benefit from enlarged print and graphics. Taken together, this is a market of significant size that is ignored by the kiosk that requires its users to be without disability and able to speak English. There is a market opportunity of similar size lost in other countries as well. Legal RequirementsAny American company with 25 or more employees must comply with the Americans with Disabilities Act, which requires that that those companies provide reasonable accommodations for employees with disabilities. As this applies to information kiosks, those kiosks must be able to accommodate all manner of disabilities, so long as the work required in the accommodation isn't deemed unreasonable in a court of law. In educational settings, federal regulations require that publicly funded schools provide reasonable accommodation to instructional information. Kiosks used as electronic card catalogs in libraries, for test taking, for registering for classes, and so forth all come under these regulations. Section 508 of the Federal Rehabilitation Act specifies that the U.S. federal government procurement process for technology must include a specification that those products be accessible. In addition, this act requires that all technology used by the U.S. federal government to interact with the public (such as web sites and IRS information), be accessible. As kiosks/ATMs are used on army bases, for voting, obtaining tax information, and so forth, they must be accessible. User ExperienceThe Universally Accessible ATM user carries with them a Java Card that specifies the user's language and locale, the look and feel to use, whether and which assistive technologies are to be loaded into the ATM, and the user's preference of ATM interface. When users insert their Java Card into the ATM, the ATM first reads information specifying language, locale, and so forth, from the Access Preferences applet running on that Java Card. The ATM then re-configures itself based on the specified user preferences. Once it has done this, the ATM then prompts the user for their PIN (in the user's preferred language and such), and carries out transactions with the user, validating that user through the banking server databases, and so forth. The following paragraphs demonstrate a few typical user scenarios: Japanese Tourist Visiting The U.S.When a non-English speaking tourist from Japan walks up to a local bank ATM machine to withdraw cash, he inserts his bank's ATM Java Card. The ATM reads from the card that this user needs the language of the ATM to be Japanese (using the Hiragana symbol system). The ATM queries its string server, and gets the localized Hiragana strings. It then continues user interaction, using Hiragana instead of English. When the tourist is finished and removes his Java Card, the ATM reverts to the English default. Spanish Businessman with Low VisionA Spanish business traveler is traveling through Europe. Upon arriving at an airport, he goes to a local ATM to obtain local currency. When he inserts his bank's ATM Java Card, the ATM reads from the card that this user not only needs the language of the ATM to be Spanish, but further that the ATM should use a specific, low-vision look and feel. The ATM first queries its string server, and gets the localized Spanish strings. Then it queries the Look and Feel server, and replaces the Look and Feel classes which make up its user interface with the new low-vision set. The ATM then continues user interaction, using Spanish and the low-vision look and feel classes instead of the default. When the businessman is finished and removes his Java Card, the ATM reverts back to the language and look and feel it had previously. Blind Student Making a DepositA blind student receives a financial aid check, and walks up to an ATM to deposit it. She inserts her ATM Java Card, and the ATM reads from the card that this user needs a commercial screen reader, which is a separate assistive technology, to provide access to the ATM user interface. The ATM queries the assistive technology server, and after verifying that this user has a license to use the screen reader, loads the screen reader onto the system. It then continues user interaction, and the user has the screen reader read the contents of the user-interface to her using speech synthesis. When she is finished with her transaction, she removes her Java Card and the ATM unloads the screen reader. Architectural details of the Java Business Expo DemoThe Universally Accessible ATM is based on a 4-tier, thin client model. The client is written using the Java Foundation Classes, and utilizes the Pluggable Look and Feel architecture, the Java Accessibility support, and the Java2D functionality in JDK 1.2 to render fonts in any language character set. In the middle tier, servers use RMI to supply the client with the main user interface, the language specific strings, the Swing pluggable look and feel classes and themes, and any assistive technologies the user might need. At the back end, a SQL database on a mainframe contains banking records which are queried via JDBC. Finally, users carry with them a Java Card which state their language and locale, and provide URLs to the Swing pluggable look and feel, theme, and assistive technologies they require. These URLs could potentially be to servers outside the bank's firewall, using signed applets and the JDK 1.2 security model.
The ATM itself can be a very thin client, since everything it needs lives on servers. The application itself comes from the server. When the user specifies a language that is different from the default, the language strings are obtained from a string server via RMI. Similarly, Look and Feel classes, themes, and assistive technologies are all loaded from servers. The ATM client only uses RMI to communicate with the bank server, which then can use JDBC, CORBA, or another mechanism to communicate with the customer and baking databases which may reside on legacy systems. User preference information is stored on the user's ATM card. This can be a Java Card or a magnetic strip card. User preference information includes the Pluggable Look and Feel classes ("Java Look and Feel", "Windows Look and Feel", "Audio Look and Feel"); Look and Feel theme ("Low vision theme of the Java Look and Feel"), and the user's country and language information.
Java Platform Technologies EmployedThe Universally Accessible ATM prototype is based on a number of technologies, all available as part of the Java platform. Java Accessibility APIThe Java Accessibility API is a contract between mainstream Java applications and assistive technologies which provide access to those Java applications. It specifies detailed information about every object that makes up the user interface of the Java application, as well as providing event notification for when the user interface changes. The Java Accessibility API is a standard extension, is part of the Java Foundation Classes, and can be downloaded and installed in a JDK 1.1 environment. It is part of the core JDK 1.2 platform. In the Universally Accessible ATM prototype, the Java Accessibility API is implemented by the ATM client application. This implementation comes virtually for free because the ATM client application is written using the Java Foundation Classes, which provide an implementation of Java Accessibility API on each of the user-interface components in the JFC. Because the Universally Accessible ATM supports the Java Accessibility API, assistive technologies such as screen readers can be loaded into the ATM from a remote server, and can read the contents of the ATM screens to users who are blind. Pluggable Look and Feel ArchitectureThe Java Foundation Classes include a set of user interface classes (the javax.swing package) which support a Pluggable Look and Feel architecture. This architecture delegates the rendering of the Java application user interface to a set of Look and Feel components, which are instantiated dynamically at run-time. In particular, the user can choose which set of Look and Feel components should be used by the program by default. This enables the user to specify a Macintosh, Motif, or Windows Look and Feel rather than the standard Java Look and Feel. Alternately, the user can specify a Look and Feel which is enlarged if they have poor eyesight, or an audio Look and Feel which uses synthesized speech if they are blind. The Pluggable Look and Feel architecture is the basis of the design of the javax.swing user-interface package, is a standard extension that is part of the Java Foundation Classes, and can be downloaded and installed in a JDK 1.1 environment. It is part of the core JDK 1.2 platform. In the Universally Accessible ATM prototype, the Pluggable Look and Feel architecture is automatically part of the ATM client application simply because the ATM client application is written using the Java Foundation Classes. In addition, the Universally Accessible ATM client is configured to switch Look and Feels based on information located on the Java Card. Because of this, users can specify alternate Look and Feels such as a high-contrast or low-vision Look and Feel (or the equivalent theme of an existing Look and Feel), and so can use the ATM even though they may be color-blind or their eyesight is failing. Java SpeechThe Java Speech API provides an architecture for generating and recognizing speech for the Java platform. Sun provides only the API, with implementations coming from a variety of vendors for specific hardware and operating system environments. These vendors include IBM, which provides a Java Speech implementation for the Win32 environment, and Lernout & Hauspie, which provides a Java Speech implementation for the Solaris environment. The Java Speech API is based on JDK 1.1. In the Universally Accessible ATM prototype, Java Speech is used by assistive technologies and Pluggable Look and Feels to speak to the user and also get input from them. This allows users who cannot see the screen to be told what is on it, and users who cannot manipulate keys on a keyboard to be able to tell the ATM what they want done. Java Card / Java Ring / Magnetic Strip CardFor the Universally Accessible ATM prototype, the Java Card API is used to communicate with an applet residing on a Java Card or Java Ring, to retrieve user reference information. Optionally, this information could reside on a magnetic strip card, and use the Java Commerce APIs to read it. These APIs are all based on JDK 1.1. In the Universally Accessible ATM prototype, the Java Card API is used by the ATM client to communicate with an applet residing on a Java Card or Java Ring to obtain user preference information. This allows the ATM to re-configured itself to use the language, Look and Feel and theme that the user specifies, as well as loading any assistive technologies needed by the user. Multi-lingual SupportAll text and characters in the Java programming language are based on Unicode. However, rendering these characters has been done by the native host font rendering technologies in JDK 1.0 and JDK 1.1, which has often limited the languages that could easily be expressed in Java applications. JDK 1.2 includes the Java2D rendering sub-system, which can render TrueType and Postscript fonts directly. With Java2D, it is easy for any JDK 1.2 application to render text in virtually any language. In the Universally Accessible ATM prototype, the multi-lingual support of Java2D and JDK 1.2 is used by the ATM client to re-render the text in the user-interface in the language specified by the user. | ||||||||
 |
|
