A significant portion of our population have impairments which reduce their ability to effectively use WWW pages. Although there is a tremendous variety of specific causes, as well as combinations and severity of disabilities, the major four categories are:Simple Java Applet design changes or alternate forms of information presentation can greatly increase the number of individuals who can use a Java Applet/application, benefiting the individual and, as the WWW becomes more commercialized, benefiting the mass market. The current direction in which www pages are evolving will automatically encompass many or most of the required features and capabilities if the new design directions are implemented carefully. Regardless of a users disability, a Java applet should present perceptible information, have flexibility in use, have tolerance for error and require low physical effort. The purpose of this Java Design Guide and Wishes is to help creators of Java applets/applications find ways to easily accommodate users with disabilities and to encourage thought about incorporation into the language Java attributes which help increase Java applet/application accessibility for users with disabilities.
Visual Impairments
Hearing Impairments
Physical Impairments
Cognitive/Language Impairments
Java Applets could be more accessible if there were descriptive attributes of/for applets and component objects in applets, methods for the user to alter communication characteristics (text/sound/sight) and a means of maneuvering among the applets' components. The descriptive attributes would elaborate on and communicate information available visually/aurally. The descriptive attributes would be accessible by methods available to the various components. These methods could be activated by the user (within the applet) or by flags set by the user in the browser. Setting browser user preference would be better, as flags would only have to be set once. Optional menus for adjusting applet appearance and communication method could be present in applets or specified by browser preferences, accessing methods in Java to alter/enhance components. Browser user preference (font, font size, etc.) doesn't presently affect applet displays of text, color or images. The state of the applet could also be altered by the user changing the param sent in calling the applet, specifying font size, color, image and sound. The choice of param could be specified by the browser preferences. The alteration of applet component physical appearance and communication functions include turning off images/sounds ( and accessing alternate forms of the information these images/sounds conveyed), providing alternate nonvisual alerting methods when a new window opens, and altering the layout (text size, color scheme, complexity). Altering the physical function of the applet could include stopping the applet in time via threads to allow a user time to respond or a screen reader user to analyze the whole screen before the screen changes. A listing ( with optional descriptions) of the components of an applet could provide a means of understanding the applet and accessing the components. On the browser level, a way is needed to move among the applets present on a page, (possibly by a speedlist providing the titles/ descriptions of the applets), a way of turning off Java applets with continued access to appplet descriptors and then a way of turning on the applet. Enumeration getAppletInfo() could be used to return attributes of applet and getAppletContext(), getApplet() for the applet to communicate with browser.
A "speed list" is a menu type listing of objects in an applet. A "speed list" of the various components in an applet would provide an overview of the applet, and a keyboard driven way of moving among and accessing the components and the descriptions of each component. If simple enough, the applet speed list could contain all the components present in the applet. Alternatively, to make applet use simpler, each Panel in a window could have its own speedlist. The components of the speedlist would be present, depending on the layout(), in a characteristic order to help the user know what to expect. The user may/may not have to be informed of the type of layout being used. The ordering in the speedlist in a logical, priority or sequential manner could be defined by default in the constructor (methods accessible to the component having the layout attribute could create the default speedlist), could be defined by the programmer or could be adjustable by the user. The layout could be treated as a table, moving among its rows and columns. Screen readers set on line reading move through the applet based on the (x,y) location value of the components. The actual physical location of a component can alter its line reading sequences from the expected sequence present in a layout. Border Layout could have a consistent priority (C,NE,N,NW...?), Flow Layout could use its natural sequence (first component to last component), Card Layout could use its natural sequence (first card to last card), and Grid Layout could be sequenced by rows or by columns. Gridbag Layout could be prioritized by the constraints and how closely the result mimics some of the other layouts. GridBag Layout speedlist component sequence may best be defined by the programmer. (Gridbag layout has a number of constraints which specify number of cells in x,y for a component to occupy and whether the cell can expand in x,y direction as the window changes size. The physical location in x,y affect how a screen reader interprets the applet.) Custom Layout speedlist component sequence may also best be defined by the programmer. A component listing based solely on x,y coordinates could present the applet components in a confusing manner. As the user moves about the physical layout and encounters components, descriptions of components would be available. The user/browser flags could determine the number of descriptive elements presented, (name of component, function of component, spatial relation of component to other components, etc.). The component would still be usable when the description mode is present. The description text would immediately show up in a manner accessible to screen readers. These descriptions could be available to all users. Text windows which appear when a component is encountered need to remain after the screen reader focus is removed from the component and shifted to the text window. Descriptors would present what panels are present in a frame or window, describe the components (Button, TextField, TextArea etc.) present in a panel, as well as the text written on buttons and Labels present and what component they are spatially associated with. The relation of Labels to other components may need to be defined by the programmer, but could be generated by a layout description method. Canvases containing draw text or objects need also be described. Some simple descriptions (canvas contains "text", three circles, etc.) might be generated automatically.
A href/link can be associated with any location or object and an action regarding that object or location. There is no standard indicator of href/links in Java Applets as there is in present HTML documents (highlighted or underlined text or images). A speed list could be an easy way to find and access href/links (AppletContext class showDocument(url)). The object, location or action which activates the href/link could be described and accessed in the listing. The presence of the href/link could also be announced/vocalized as encountered in moving about the applet. Since Java Applets are dynamic, the active status of the href/links could change.
Text size/quality can impact accessibility by affecting readability and by communicating information. If the font, font size, color of text, and changes in these qualities communicates information, the information should be accessible to the user by alternate means. The existing conditions could be given in the applet/component descriptive attribute. The changing of these qualities could be indicated by a pop up alert or verbalization. To make text more readable, the user should be able to adjust text size, default to a larger text version or access the system default settings. Presently browser text font/size preferences do not affect applets. The text of components [Label, CheckBox, Button, Dialog Box, Menu, Choice, TextArea or TextField] and text of the graphics drawString() have methods for altering text and providing information to make the altered font work in the format [setFont(), FontMetrics class, setMaxAscent(), setMaxDescent(), stringWidth()]. It would be nice if text characteristics could be specified by the users browser preferences. Increasing the text size may create formatting problems. Thresholds of font size changes could be defined where layout wouldn't have problems. Increasing the font size as the applet is loaded may be easier on formatting problems than changing the font size after the applet is loaded. If the layout has to change to accommodate a font size change, increasing the window size (added scroll bars?) might help. Possibly, the preferences font size of the users browser could derive screen dimensions and access resize(), to change the applet's window size as the applet loads or as the user changes the font/font size. Resolution of the users monitor may affect applet display, a laptop screen vs. a high resolution screen. Resize() could be used to standardized the applet presentation. CloseView, a screen magnifcation control panel (mac), can be used to magnify the screen , and in turn the Java Applet. If a low vision user only magnified a region of the screen with resize(), or if only selected text had its font size changed the format would have problems. The text could be replaced with the same text with the font size increased using replaceText(string, start, end). If rendering text with g.drawString(String s, int xcoor, int ycoor) mixing fonts and sizes can create problems of positioning strings. Getting the start and end points to mesh with other objects in the container/component could use [setFont(), FontMetrics class, setMaxAscent(), setMaxDescent(), stringWidth()], but could cause formatting problems. The selected text/magnified screen region could be sent to a dialog window, a magnified version of the focus area of the applet, with its own increased font size/ object size.
Screen readers can access text present in applets, in a line by line manner, based on x,y coordinates. Menus, text on buttons (and the button is identified as a button), pop up frames and dialog windows are readable. Java Applet Frame Menus can be navigated by key commands in Windows95. F10 activates the menu, Alt-letter activates menu item with label starting with letter, arrow keys allow for menu navigation, and letter keys change focus item in pull down menus (first letter of label)(Jon Gunderson). Some components of the applets have access problems, which are discussed below. [Here is an example Java Applet demonstrating the different Java AWT components and a Java Applet demonstrating some of the accessibility problems.]
An image alt text or a descriptor is needed in Java Applets. A no load image user option/browser flag could be helpful in presenting a simpified version of the Java Applet to the user. If an object is drawn, it would be useful to provide a descriptive attribute to describe the object and its position/action in relation to other objects. Presently the screen reader just speaks a graphic number for each part of the graphic. An example of this is in this ballon applet. The parts of a graphic could be grouped together and given a name and a descriptive attribute. The screen reader could encounter one composite graphic object instead of all the parts of the graphic object. The description could be provided by the programmer, or if the relationships are simple, the layout relationships could be used to create a unique sentence describing the situation. If a complex object is created using a method or class (i.e. class car method draw car), a descriptor tag creation method could be associated with the method/class. The descriptor tag could adjust to the instance of the method expression (red car, green car, car with no bumper). Information would be lost to some users if an object is created that is unique and unpredictable, where an appropriate descriptor could not be provided in advance. Image descriptors attributes would be part of the image file/descriptor class, accessible when ever an image is present. Descriptors should also be available for background tiled images. Layering of images and interaction of images could be confusing in textual/aural descriptions. To reduce confusion, a simplified alt view might be optionally presented. The simplified alt view could consist only of those images which communicate essential information. Background and purely decorative images would not be described, unless requested. Users could access a descriptor flag in the applet or set default flags in the browser for routine access to simplified view. The descriptor field of an image would be accessible whether the image is present or not (image presence could be needed for applet function). Could an image be "present" for the function of the applet, yet not shown be on the screen?
The user should be able to adjust the color scheme to reduce display complexity or increase contrast. Default settings could be accessed from the browser (user set activation flag) preferences ( a high contrast default , light and dark colors, will allow things to be told apart even if the user is color blind)., The color scheme choice could be made before starting the applet by the param sent to applet, or adjusted by the user in the applet.[g.setColor(color.red)]
Color alone should not be used to communicate essential information. If color is the communication "event", a descriptor, created by programmer, accessible to other medium should be available. If other communication methods are not incorporated into the display, user choice/browser flag could trigger descriptor field access/ display. The color isn't the object, the color's communication of information/ event is the object which would have the associated descriptive alert/tag.
Occurrence of background visual events need to be cued by sound (non-verbal or verbal) or descriptive text (screen reader text/verbalize). An example could be a graphic of a changing thermometer. The thermometer is not changing all the time, so need only tell the user when it does change, and how it changes. The added descriptor information could be activated by user choice/browser flag, be part of the class thermometer, and be available in nonvisual media or text accessible to screen reader. Another example is a graphic of a pressure gauge needing a TextField labeled pressure providing the pressure in an accessible text format. A example of this need is in this Ballon Applet. Methods are needed to verbalize a component (scrollbar, choice), provide the name, provide a description and tell the state or value (scrollbar.getValue()), to make the information available in alternate media. The CheckBox state is accessible to the screen reader, but the value of a scrollbar is not accessible. The user could be allerted by a aural or a textual/screen reader cue to the temporal occurrence of a Dialog box, FileDialog box, Menu, MenuBar and Exceptions. Avoid using mouseEnter(), mouseExit() to trigger events. The visual event of moving the mouse to a region should require an active user action to trigger an event
Sound alone should not be used to communicate essential information. If sound is the communication "event", a descriptor field accessible to other medium should be available. If other communication methods are not incorporated into the display, a user choice/browser flag could activate methods to access a descriptor field. An alternate or added to form of the audio file/movie could be available to the user, providing a description of the sound or in line text (accessible to screen readers).
Threads could be used for freezing the display window while the window can be analyzed and responded to. By the time a text reader works its way down a page, a constantly updated text stream may not be relevant to material read earlier on the page. All the threads changing the screen, present in different applets, have to be suspended in a coordinated manner. The screen reader access thread could become active in a number of ways. The thread could call an operation that will not return to its caller until input and output operations are complete (blocking on input/output). The operation could be the screen reader finishing the page. Wait() could be used in synchronized threads. Synchronization of the threads causing screen changes with a thread for screen reader access could allow the screen reader thread to interact with the monitor and block the screen updating threads. The other threads would call wait() after a screen update, and the screen reader thread would call notify() or notifyAll() when the screen was analyzed. Synchronization of threads takes time and would be difficult across applets. Yield() would allow the evaluation of the priority of threads, and the screen reader access having a high priority thread could become and stay active. The priority of threads could be altered by user/browser choice or defined in the applet so the screen reader thread has a high priority. Suspend() could be called in the thread, and resume() could be called by the screen reader thread. The threads which affect screen update could be coordinated by being members of a threadgroup, allowing all the members of the threadgroup to suspend()/resume() at once. Knowing the number of active threads, activeCount(), in a screen update thread group could determine if the screen reader access thread would keep control. The screen reader access thread could be a daemon, setDaemon(), only active when other threads are active. Can the group of active threads dictating a daemon's active state be defined? Sleep() could be used if the time of sleep could be adjusted. Maybe, interrupt() could be called outside the program to allow the screen reader access thread to become active, (more drastic). Although handling exceptions is time consuming, maybe the user/browser/screen reader could throw an exception which is predefined exception designed into the applet to be handled by freezing the screen update. When the screen had been analyzed the user could get rid of the exception.
The screen reader used was OutSpoken in combination with Netscape 2.0 / Windows95. If you discover problems with any other combinations of computers, screen readers and browsers, please email info@trace.wisc.edu.