TEXT ANCHORS

The problems:
People who use ATs to access the information on a web page will often tab through the links on a page. Although this allows quicker identification of links, users will lose the context of the link.
Solution Strategies:
In a speed list of text anchors, provide text anchor descriptions good enough so that they make sense when read out of context. This will allow a person using an AT who is skipping from link to link to select a link without needing to read a whole section to determine the context. For example, if you use several "click here's" on a page, not only will it be difficult to distinguish between the links, but where they go. The speed list can be provided by the developer or generated automatically as a resource of the anchor objects.
TEXT LAYOUT

The problem:
Tabular layout of text causes problems for people with blindness or low vision that use AT software since text is read by row rather than column. If the text is presented in newspaper column format the first line of each column is read as one line, then the second line from each column, etc.
For example:
There is a 30% chance of rain showers this morning, Classes at the University of Wisconsin will resume on
but the weekend looks like it will be sunny. September 3rd.

This might be read as:
There is a 30% chance of rain showers Classes at the University of Wisconsin this morning, will resume on
but the weekend looks like it will be sunny. September 3rd.

Solution Strategies:

1. Avoid placing text in columns. Design a layout that can be readable by ATs. Depending on the context of the text in your layout, your layout may be accessible. For example, if you have a list of choices in a layout the content of the cells are not dependent on one another.

Some screen readers, e.g. outSPOKEN 1.2 beta, Window Bridge), are able to read columnar text. Active Accessibility allows columns to be semantically grouped differently, with a Browser exposing those groups via Active Accessibility.

2. Make a text-only version of the page containing the layout.

BITMAP TEXT

The problem:
AT software can not access bit-mapped text, perceiving it only as a graphic. An examples of this is a graphic acting as a logo or heading. (to more information on graphics).
Solution strategies:
Try to use the Java text or string drawing methods, whose text are then accessible to screen readers. If use of bit-mapped text is unavoidable, make sure the content is available elsewhere as text. An ALT-TEXT or descriptive attribute is needed for graphics in Java.
TEXT SIZE

The problems:
Users need to be able to adjust the size of text for easier viewing (whether they are giving a presentation or have low vision for some other reason).
Page layouts can be affected by users adjusting the font size of browser displays.
Solution strategy:
Let the user specify the font size when loading the application/applet (param), in the user system/browser preferences, or from with in the application/applet. If the change in font size affects the layout of the application/applet, resize the whole application/applet window proportionally.
TEXT COLOR

The problem:
Poorly contrasting colors.
Solution strategy:
Make the text and background colors contrast so that they are readable on a monochrome monitor. Let the user specify the text color when loading the application/applet (param), in the user system/browser preferences, or from with in the application/applet.
PUNCTUATION AND SYMBOLS

The problem:
AT software often ignores or stumbles across punctuation or words in capital letters.
Solution strategies:
Avoid presenting text in all capitalized letters. ATs may interpret capitalized text as an acronym and start spelling it. Put spaces between letters in an acronym. This ensures that ATs will spell the acronym rather then try to pronounce. For example: H T M L. Avoid uncommon typographic characters or constructions (emotions ;-), arrows consisting of dashes and greater-than signs -->, etc.) The screen reader will either ignore them or try to pronounce each symbol.

Another solution is a text object resource which describes the symbol or punctuation.
TEXT THAT CHANGES OR MOVES

The problem:
Blinking and constantly changing text is unreadable by or freezes AT software.
Solution strategy
Don't use blinking or constantly changing text or provide a means of suspending/resuming the screen updates/changes.

Active Accessibility provides another solution. The Browser knows the HTML code for marque text and programatically makes the actual text available directly via Active Accessibility.

LAYOUT

General Statement of Problems:
The Java AWT allows text to be laid out in side by side paragraphs and other formats which cause difficulties for screen readers which will usually read a row in a layout as a sentence.
General solution strategies:

1. Keep layouts simple and straightforward.
2. Avoid side by side presentation of text.
3. If using graphics to provide organization or structure to the document, attach alt-text descriptive attributes to images that supply the same changes in context that the visual cues provide.
4. Where the previous three guidelines would interfere with the presentation of the information for some reason, a text-only application/applet which presents the same information in an accessible format could be used.
5. Buttons that perform the same function on different application/applets (for example, "return to home page") should be located in the same location on every application/applet.

TABULAR TEXT

The problem:
Some text layouts cause problems for AT software (used by people who are blind) since ATs tend to read across the screen in a way that runs all of the text on a line together. If an entry in a cell occupies more that one line the first line of each cell would be read, then the second etc.
Solution strategies:
Layout the text so it will make sense when read across the screen.
Maybe put long text in it's own window, so screen reader stays in the new window to read text (don't know if this will work.) Active Accessibility allows the creation of a table object, with rows, columns and cells, with a Browser exposing these groupings via Active Accessibility.
FOCUS/BLUR IN APPLICATIONS/APPLETS AND CHOICE OBJECTS

The problem:
There are difficulties using keyboard navigation to enter/leave application/applets and the java choice component.
Solution strategies:
The nature of the frame/window of the application/applet and java choice component needs to be altered so the AT's keyboard navigation works.
Keyboard navigation should be supplied in the browser and within the application/applet.

GRAPHICS

IN-LINE GRAPHICS

The problem:

1. People who are blind cannot view information that is presented (only) in graphic form.
2. People (anyone) who are accessing information over a slow network connection (e.g., modem) have only very slow access to pages with graphics.
3. If Web documents (or their derivatives) are to be made available via phone or other auditory channel then some alternate method for presenting information that is presented in graphics would be needed.
4. People who are accessing information with a text-based browser such as Lynx have no access to graphic information.
5. People with manual or cognitive disabilities, people who cannot read, etc. may have difficulty understanding or interacting with information that is presented only in text form.
6. Some people have a need for graphics while others can not access them, it is important that applets are as flexible as possible.

Solution strategies:
1. Graphics need the information contained in them presented in an alternate format such as a ALT-TEXT descriptive attribute associated with the images object. The information could include descriptions or change of context indicators. The presentation of the descriptive attribute may affect layout, so a new dialog window could be used. Decorative images could be ignored for a simplified layout or briefly described. An alternate text only version of the application/applet could be available.
2. A no graphic version of an application/applet could be smaller for fast downloading. The choice of Application/Applet could be made by the user or determined from the system/browser preferences (auto-load images turned off). 3. Auditory presentation of graphic information from accessing ALT-TEXT or other image object descriptive attributes

ACTIVE IMAGE AREAS

The problem:
Active image areas, like image maps, allow users to click on "hot spots" of a picture and initiate an action event. This type of feature, which requires an ability to see and click on particular parts of a graphic image, is completely inaccessible to people who are blind. Even if the picture is described, they are unable to detect where to click. Active image areas can be used in a wide variety of ways. Some uses are rather simple like nice looking menu bars. Others are more sophisticated, like graphic representations of maps, diagrams, etc.
Solution strategies:
1. Next to (or just below) the Active image areas graphic, provide a text anchor or button which will initiate the action event. This is easy, but removes the action initiation event from the context of the rest of the page. As a result unless the context is also explained, this approach is not generally recommended.

2. (recommended). Have a button initiate to a text-only Java application/applet which presents an alternate form of the entire application/applet. Replace the active image areas graphic with a list of text anchors/buttons of the action initiation events available through the active image areas graphic.

3. (also good if done in a way which avoids confusion). Provide a listing of active image areas graphic choices as a list of text anchors or buttons immediately below the active image areas graphic. This sometimes works, but can also be confusing. The ALT-TEXT or descriptive attribute of the active image areas graphic should say that choices are provided in text form following the active image areas graphic.

4. Build a new Active Image Area object in AWT and encourage developers to use it. Encourage browsers to expose these via Active Accessibility/etc.. Support Tabbing (CTRL-tabbing) between these and use the system notion of "focus" for all of the different areas. Fundamentally if you can do it from the keyboard only, you've done most of thework of supporting accessibility software.

COLOR

The problem:
Background graphics, text colors and colorful images are being used fairly frequently in the design of Java applications/applets. Although this may make the page appear more attractive or memorable to some, to others it is not readable. Users cannot override the source code through configuration options available in most current browsers.
Solution strategies:

1. Background patterns and color should contrast well with the lettering to maintain readability (background refers to both backgrounds of pages and backgrounds of images.) Using dark shades of blue, violet, purple or black lettering on backgrounds of light shades of blue-green, green, yellow or orange are easiest to read. Avoid using similar hues together. For example, do not place blue-green lettering on a blue background (Arditi, 1995).

2. Select colors that will make your pages easy to read by people with color blindness. One good test is to see if your pages are readable on a monochrome monitor.

3. Make color coding redundant with other means of conveying information.

4. Let the user specify the color options, in the (param) sent to the application/applet by user choice, in the color preferences set by the system/browser, or within the application/applet to present a different version of the application/applet.

ALT-TEXT AND DESCRIPTIVE ATTRIBUTES FOR GRAPHIC OBJECTS

The problem:
There is no descriptive text associated with Java application/applet images.
Solution strategies:
Create a new AWT image object that contains alternate text that the browser/application can see and expose to accessibility aids (via Active Accessibility, etc.). Resources should be associated with images which describe the image sufficiently for the user to understand the applet. The descriptive attributes could come in various levels of detail, e.g. name of image, short description, and in-depth description. The description could be read by the screen reader without every being written to the screen. If the description is short enough to not disrupt the layout of the application/applet, the text could be written to the application/applet. If the user wanted to write a long description resource, it could be presented in a new dialog window.

MULTIMEDIA

AUDIO CLIPS

The problem:
1. People who are deaf cannot access information which is presented in auditory form only.
2. People without audio capabilities in their computer do not have access.
3. People in noisy environments may not be able to hear information presented audibly.
4. People may want a printed transcript of the dialogue of the movie.
5. People may want to search for a certain section of the audio clip, or allow keywords to be identified by web crawlers.

Solution strategies:
The problems and solution strategies for audio clips are very similar to those for animations or graphics:
1. Let user choice or system/browser preference in loading the application/applet, or choice within the application/applet access a text transcript or description of the sound. This could be a text only application/applet or a text/sound enhanced application/applet.
2. Create a new AWT audio object that contains a resource to store the transcription, and encourage developers to use it (development tools should flag an empty transcription, warn if the length of the text seems unreasonably small relative to the length of the audio data, etc.), and browsers/applications should expose this upon request. The transcript resource would also be useful for computer-searching. Access can be accomplished by allowing text to be stored in the data structure.
3. Servers should be able to send the sound format, the text format, or both, on request from the browser.
4. Players should be able to present the sound format, the text format, or both formats.
5. Sound formats should include the ability to simultaneously present the text version of the audio information.

ANIMATION
Java application/applets don't have movies yet, only animations. The problems encountered with animations are the same as will be encountered with movies, though there will be differences with formats.
The problem:
The only known way to make animations accessible to people with disabilities is to embed the accessibility information in the data stream so that it is time-synched with the other information.
Two types of alternate format information are needed to make animations accessible:
Audio: Captions or other visual representations of all important information in the sound track should be provided. (Some data structures such as QuickTime movies already have a mechanism for adding captions to the data structures.)

Animation: For people who are blind or who have low vision, a technique called Descriptive Video is used which provides an additional narrator describing what is happening, in between the regular dialog of the movie.

Text transcripts should be provided for both Audio and Video for users with text-based browsers and/or no helper apps.
Solution strategies:
Captions (for those who do not have access to sound)
1. (Recommended) If the external viewer being used will display "closed" or embedded captions (e.g. Quicktime) , captions can be embedded in the data structure of the movie.
2. (Good Alternate) A strategy which works for all movie viewers today is to have an alternate version of the movie available with open (permanent) captions which a user can choose instead of the uncaptioned version if they wish.
3. (Good as supplement) In addition to providing captions in the movie, it is also useful to provide a separate transcript of the audio track of the movie. It usually takes quite a while to download a movie file, and a text transcript of the audio can usually be downloaded quickly and allow one to prescreen the item before deciding whether to take the time to download it.
Descriptive Video: (For those who do not have access to the video portion of the movie)
1. If the movie format allows alternate audio tracks (e.g. QuickTime) you can provide an alternate track which includes the descriptive narration.
2. If your movie format does not, you can provide an alternate form of the movie with the descriptive narration included in the audio track.
3. In addition to providing a transcript of the basic audio track of the movie, it is also useful to include the text of the Descriptive Video in the transcript.

PPLICATION/APPLET COMPONENTS AND FUNCTIONALLY EQUIVALENT COMPONENTS

The problem:
At the present time it is difficult for some ATs to recognize some application/applet components. The Scrollbar object is recognized as an image. An Image acting as a button is not recognized as a button, but as an Image. This problem could continue to grow as more objects (ActiveX and OpenDoc components) and custom AWTs are used in Java application/applets.
Solution strategies:
Identification/description information could be associated with an object during its' implementation, providing the name of the object, identification of the functional object type, a short description of the object, and a long description of the object. An image acting as a button would have its' functional object type defined as a button. This identity could be provided via Active Accessibility/etc. or by the way the browser/application peers the object with an equivalent in the native OS.

There is a 30% chance of rain showers this morning,	Classes at the University of Wisconsin will resume on
but the weekend looks like it will be sunny.	September 3rd.