Applets are small programs, generally written in the Java programming language, delivered as Web content and carried out by the user agent. Applets depend on other programs to convert the Java program code into usable instructions for the user device. Originally developed by Sun Microsystems as a multiplatform, platform-independent, object-oriented programming language, Java allows versatility limited only by the imagination of the programmer. Many Java applets are freely available for download from the Web to perform a variety of functions, from simple tasks such as special visual effects to more complex functions such as weather simulations, site search engines, online games, and mathematical and financial calculations. As applets were introduced to the Web via Sun's HotJava browser, they excited the industry but posed serious accessibility barriers.
Most assistive technologies are not written to support the Java platform, so Java environments, including applets for the Web, were completely inaccessible to most assistive technologies for several years after Java was launched publicly in 1996. The Trace Research and Development Center, in Madison, Wisconsin, fostered cooperative, industry-wide research to address the accessibility problems created by Java applets. In 1998, Sun introduced the Java Access Bridge, a technology targeted at developers of assistive technologies, to enable designers to create products that can work with Windows and Java applications. The Java2 platform introduced the Java Accessibility API, which has the goal of creating the appropriate hooks to allow assistive technology devices to interact with Java applications.
Welcome progress, indeed, but the actual application of the technology is still in its infancy and requires very specific conditions in order for assistive technologies to accurately render the dynamic information usually contained within Java applets. Sun and IBM are to be commended for their excellent work on the Java Accessibility API. In March 2001, the American Foundation of the Blind cited the achievements of Sun's Accessibility Team and presented Sun with the 2001 Access Award for building accessibility into the Java platform.
As with many new technologies, however, while the promise is great, the reality is that we must still incorporate inclusive design strategies to ensure that our use of applets delivers important information and functionality to all users. Version compatibility between the Java Access Bridge and the Java RunTime Environment has been an issue. Browser considerations, installers, and keyboard control continue to affect the ultimate accessibility of Java applets for users with disabilities. Alternatives are therefore still needed; in many cases, fortunately, those alternatives are not difficult to provide.
ALT Text for Java Applets
The first accessibility goal is to ensure that the user of a text-based browser or assistive technology device is made aware that the applet exists on the page. In addition, the purpose of the applet must be communicated. These two goals may be accomplished simply by following the "prime directive" of accessibility to provide equivalent alternatives for all nontext elements on the page. The <applet> tag should include an explanatory alt attribute (and may even contain a graphic image) to give all users more information about the missing content.
Suppose we have a Java applet that creates a scrolling ticker tape on a Web site. Its code might look something like this.
<applet code="TickerTape.class" width=460 height=160 param name=appletParameter1 value=value alt="An applet of a scrolling ticker tape with information about cur- rent stock prices. A static listing is updated daily at http://staticpage.com."> </applet>
A browser that doesn't render the <applet> tag will ignore the <applet> and <param> tags, instead interpreting any HTML code between the <applet> and </applet> tags. (The alternative HTML code should appear after the last <param> element and before the tag that closes the <applet> element.) This is one method for providing equivalent alternatives to content that might be generated by an applet. For example, if the applet demonstrates the steps involved in a process, the alternative HTML code might provide a sequence of static images representing those steps, along with appropriate ALT text and extended descriptions. This technique is similar to the one we recommended in Chapter 13 for using the <object> element to display alternative content when Flash or other necessary plug-ins are not available on the client computer.
Note that the <applet> element is "deprecated" in HTML 4.0, and the W3C encourages developers to use the <object> element as the way to embed Java applets on their pages. However, browser support for the <object> element is still inconsistent, so you'll need to make sure that your target browsers support what you're trying to do. When using the <object> element for applets, you must of course still provide equivalent alternatives as described.
Providing truly equivalent alternatives for applets that perform more complex tasks such as simulations or dynamic visualizations of large data sets is a nontrivial challenge for which there are no ready-made solutions. The best advice we can offer at this time is to consider other alternatives from the outset. Consult the Section 508 accessibility standards for software as well as those for Web accessibility; refer, also, to documentation for Microsoft's Active Accessibility API and to materials about Java accessibility produced by IBM and Sun Microsystems. The National Center for Accessible Media provides excellent references to these and other materials about accessible software design in its guide, "Making Educational Software Accessible," available at http://ncam.wgbh.org/cdrom/guideline/. (This guide is well worth reading even if you are not producing educational applications.) The U.S. Access Board has also provided a detailed guide to the Section 508 software standards; the guide is available at http://www.access-board.gov/sec508/guide/1194.21.htm.
Finally, allow yourself to consider the possibility that Java may not be the right language at this time. As the Access Board's guide cited above puts it, "In some cases it is possible that a particular programming language may not possess the features necessary to fulfill these requirements. In those instances, another language for creating the program would most likely have to be considered for the product to meet the standards" [U.S. Access Board 2001]. As we saw in the example from the 2002 Winter Olympic Games, full functionality can often be delivered in a more accessible fashion.