please send them to jb@trace.wisc.edu., Trace Center, UW-Madison. ( last modified 9/10/96) Return to Java Accessibility Project Main Page.
Go to Development Tools (Recommendations).
Making Java Applications/ Applets More Accessible:
Applet Creator Guidelines - Recommendations
Incorporating the following 8 design considerations can make Java Applications/Applets more accessible. These design considerations are based on the present state of the Java AWT. Future changes in the Java AWT will address many of these problems.
-
1. Provide important information in more than one medium.
2. Events should be triggered by active user input.
3. Let the user modify application/applet appearance and presentation medium.
4. Describe the application/applet contents, actions and layout.
5. Provide a means of navigating within the application/applet.
6. Notify the user of screen changes.
7. Text accessibility by assistive technologies.
8. Provide menus to access commands.
Screen Reader, Browser, and OS Combination Used in this Evaluation.
1. Provide important information in more than one medium.
Important information and the occurrence of events should be presented to the user in multiple media. The non accessible media could be visual or aural. The information associated with spatial relationships, images, color, text characteristics, visual events and changes (i.e. dialogbox), analog displays and sound can be presented in multiple or enhanced ways. Color.
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. The color isn't the object, the color's communication of information/ event is the object which would have the associated descriptive alert/tag.
Images.
There is no image alt text or description resource in Java, so descriptions of an image should be provided. If the image is used as a button or other event creator, its nature and function should be described.
Sound.
Sound alone should not be used to communicate essential information. If sound is the communication "event", a descriptor resource accessible to other medium should be available. 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).
Scrollbar.
The Scrollbar component is identified (by some screen readers) only as a graphic, not as a scrollbar. The value of the Scrollbar should be accessible to the user in a nonvisual manner (scrollbar.getValue()). The value of the scrollbar could be presented in a Textfield. The Scrollbar vallue could be adjusted by the user from the Textfield or by keyboard methods (e.g. arrow keys, pageup/down).
2. Events should be triggered by active user input.
Avoid using mouseEnter(), mouseExit(), gotFocus() or lostFocus() to trigger events. The visual event of moving the mouse to a region should require an active user action to trigger an event, such as keyDown(), keyUp(), mouseDown, mouseDrag(), or mouseUp(). The nature of the event will determine if passive or active triggering events are appropriate.
3. Let the user modify application/applet appearance and presentation medium.
Allowing the user to alter the presentation, format and content, of theapplication/applet could involve a number of changes. (1) Video could be presented with subtitles, (2) Text could be presented as speech, (3) Sound could be presented as text, (4) The text size or color scheme could be altered, or (5) Screen updates could be suspended until the user could respond or analyze the screen. Text Size.
To make text more readable, the user should be able to adjust text size. 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()]. 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 application/applet is loaded may be easier on formatting problems than changing the font size after the application/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 user'ssystem/ 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. The text drawing starting point could be related to the window size. The proportional increase in window size could be used to define a proportional new text drawing starting point and proportional increase in text font size. Color Scheme.
The user should be able to adjust the color scheme to reduce display complexity or increase contrast. Default settings could be accessed from the system/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 application/applet by the param sent to application/applet, or adjusted by the user in the application/applet.[g.setColor(color.red)] Suspend Screen Updates.
Allow the user to suspend/initiate screen updates. By the time an AT device works its way down a page, a constantly updated text stream may not be relevant to material read earlier on the page. Threads could be used for freezing the display window while the window can be analyzed and responded to.
4. Describe the application/applet contents, actions and layout.
Provide a summary of the application/applet and explanations of the relations between and functions/actions of the objects in the application/applet. Headings or the names of buttons can convey how a group of buttons are related or what they do. The object's class could be extended/overloaded to include an accessible text description of the object and actions. Try to use the AWT components instead of creating your own equivalents. The AWT Button component is recognized as a button by the screen reader, but an image created to act as a button is seen as a graphic by the screen reader. If a custom image is used as a button, make it identity as a button clear to the nonsighted user. When the Java AWT includes an image-button object, use this instead of your own image acting as a button.
5. Provide a means of navigating within the application/applet.
Application/applet design can accommodate the line by line, left to right movement of AT devices. A navigation aid could be provided by a priotitized listing of application/applet contents with a mousedown or keyboard shortcut event bringing the cursor focus to the object. In the application/applet, being able to TAB from object to object would be helpful. Providing a good keyboard interface can increase accessibility for users with a variety of disabilities. Java 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). Only some Java objects (button, checkbox, textarea, textfield) are tabbable to. In a scrollable field, the page down key doesn't work. A pagedown/pageup mechanism and optional scrollbar value would be useful on all window/textarea scrollbars.
6. Notify the user of screen changes.
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 resource. The changing of these qualities could be indicated by a pop up alert or verbalization. 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 descriptive resource 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. For a deaf-blind user using Braille a generalized API Active Accessibility notification accessible to the Assistive Technology device is more appropiate. Visual changes in the analog value of the Scrollbar component (scrollbar.getValue()), need to be presented in a digital manner or alternate media. The user could be alerted by a aural or a textual/screen reader cue to the temporal occurrence of a Dialog box, FileDialog box, Menu, MenuBar and Exceptions.
7. Text Accessibility by Assistive Technology Devices
Screen readers primarily access text present in applications/applets, in a line by line manner, based on the (x,y) coordinates of objects left to right, top to bottom. Menus, text on buttons (and the button is identified as a button), pop up frames and dialog windows are generally readable. (JAWS locks up with a pop up dialog window). Some components of the applications/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.] Here is a list of seven problems with text access by screen readers in applications/applets.
-
1. A Choice component is treated as a separate window by the screen reader, and it is often difficult for the screen reader to get out of. This occured with outSpoken and JAWS.
2. In the List component, the (x,y) coordinates of the scroll bar are are higher than the coordinates of the lowest visible Choice item, so the scrollbar is read by the screen reader before the lowest visible Choice item is read. This behavior occured in the outSPOKEN screen reader; other screen readers may behave differently.
3. TextField text which isn't visible is unreadable (the only way to reach it is to delete the visible text to bring the hidden text into the display area). Active Accessibility is specifically addressing this.
4. TextArea scroll bars are hard to find and hard to operate. Active Accessibility is specifically addressing this.
5. The locational information present visually with the Label component in relation to other components is lost to the screen reader.
6. Text included as an image do not have any type of alt text, so is totally inaccessible. Text created using drawString("") is accessible.
7. The bottom status line of the browser can be accessed from the applet with getAppletContex().showStatus(""), but is unreachable by some screen reader. This is a individual screen reader specific problem, and should go away. Maybe redirect the showStatus("") information to an accessible site (a pop up frame?).
8. Provide menus to access commands.
When commands can be accessed through menus, access software has very little trouble in both accessing listings of the available commands and activating commands. Commands which are issued in other fashions - such as tool bars, special palettes, etc. - present problems. It is difficult to get a listing of all of the commands (for example to someone who is blind). It is also difficult to directly activate the various commands (for example, by an alternate access routine for someone with a severe physical disability). Where all of the palette and tool bar commands are available via a menu, this is not a problem. When these commands, however, are not otherwise available, it is important that access somehow be achieved.
Screen Reader, Browser, and OS Combination Used in this Evaluation
The screen readers used were OutSpoken and JAWS in combination with Netscape 2.0 / Windows95. If you discover problems with any other combinations of computers, screen readers and browsers, please email cailling@facstaff.wisc.edu.