Design of HTML (Mosaic) Pages to Increase their Accessibility to Users with Disabilities Strategies for Today and Tomorrow

Gregg C. Vanderheiden Ph.D.
Trace R& D Center, University of Wisconsin – Madison

Prepared under funding from the National Institute for Disability Related Research (NIDRR), Office of Special Education and Rehabilitation Services (OSERS), US Dept. of Education and in cooperation with the NCSA Mosaic Access Project.

Overview

When discussing the accessibility of Mosaic, it is important to break the problem down into the three basic components: the source material, the pipeline, and the viewer. Mosaic is actually a viewer, so technically speaking, making Mosaic accessible really would apply only to making the (Mosaic) viewer accessible. However, most users do not differentiate between the different components, so making Mosaic accessible would involve working to make the Mosaic software accessible (including all of the external viewers used with it), as well as working to make source material formats and server/pipeline standards more accessible as well.

Making HTML (Mosaic) Documents Accessible TODAY

There are some features in Mosaic which are not currently accessible to people with some disabilities. In addition, many of the data formats currently do not support accessibility annotations (captions, vocal and text annotations, etc.). As a result, if you want to create WWW documents that will be accessible to people with disabilities TODAY you need to either avoid using some features and data types or provide alternate methods for carrying out the functions or information provided through the inaccessible functions.

In the future, alternate access methods for the standard features may be built directly into Mosaic, as well as the standard data storage and transmission formats, making it unnecessary to avoid features or build redundant mechanisms into your HTML documents. Until these alternate access features and standards aare developed however, care must be taken in the design of HTML pages it they are to be accessible to users with disabilities

General Comments

It is possible today to make Mosaic (HTML) documents that are accessible by simply avoiding the aspects of HTML or Mosaic which cause the access problems. For example, if you create a document which ONLY has text and hypertext links (no graphics or sounds), then you will have a document which can be accessed by most anyone with a disability using a personal computer that has been adapted for their use. Although this is a rather elementary and restricted use of Mosaic and HTML, it is nonetheless a viable approach, as is using gopher and ftp. However, a Mosaic/HTML document does not need to limit itself to text to be accessible. There are a number of strategies that can be used to allow use of graphics and sound while still maintaining accessibility.

• Some of these strategies require changes in either the WWW servers or in Mosaic.
• Other strategies, however, do not require any changes and can be used today.

Organization of this document

Problems in access to HTML fall into several basic areas:

1. In-line graphic elements, pictures, and diagrams;
2. Separate viewer based graphic elements, pictures, and diagrams;
3. Audio clips;
4. Movies;
5. Image Maps;
6. Forms
7. Specially formatted documents; and
8. Custom data structures and viewers.

Each of these is discussed in turn. For each topic, a brief overview of the problem is presented followed by how it should or will be possible to handle the problem in the near future as access features are built into Mosaic et al. (e.g., NetScape, W3, etc.). This is then followed by things that can be done to make HTML pages available today. A summary listing of what can be done today is provided at the end for convenience.

IN-LINE GRAPHIC ELEMENTS, PICTURES, AND DIAGRAMS

The problem:

• People who are blind cannot view information that is presented (only) in graphic form.
• People WITHOUT disabilities but who are accessing information auditorially (e.g., by phone) cannot access this information.
• People (anyone) who are accessing information over a slow network connection (e.g., modem) have only very slow access to pages with graphics if the auto-load images features is turned on OR no access to the graphic information if the auto-load image feature is turned off.

The solution in the future: All graphic elements would have a text description attached to them which can be viewed instead of the graphic.

All viewers (Mosaic, NetScape, etc.) will provide the option of showing the graphic, the text, or both.

Today there is such a feature for in-line graphics. It is called ALT-TEXT. It is an option within the IMG definition and allows authors to attach an alternate text description to any in-line graphic. The form for this is:

<p><a href="http://www.your.host"><img alt="Alternate text describing the picture." src="http://www.your.host/filepath/filename.gif" /></a></p>

Solutions today

Today, therefore, you can/should use one of four approaches:

1. Alternate pages: Provide a second version of the page which does not include any in-line pictures for decoration or for anchors. Instead, text descriptions and anchors would be used. A note at the bottom of each page could allow users to move back and forth between the graphic and text-only versions of the page.
2. Embedded text descriptions: Incorporate both the graphic AND TEXT within the anchor. The ALT-TEXT text should also be included for those browsers that support it. However, since the graphic browsers do not currently support it, it should not be relied on. The format should therefore be: Recommended format today: Running text on the page

<a href="http://www.your.host/path/filename.html"><img alt="Text describing picture." src="http://www.your.host.path/filename.gif" /></a>

running text that could serve as an anchor instead of or in addition to the in-line pictures of running text…

An example:

The newest product in our line is the <a alt="[Picture of Magicom Phones]" src="http://www.xyz.com/products/images/magicom.gif" <img="" href="http://www.xyz.com/products/magicom.html">Magicom portable phone</a>, the world's smallest portable pocket phone.

which yields:

The newest product in our line is the[Picture of Magicom Phones] Magicom portable phone, the world’s smallest portable pocket phone.

OR

The newest product in our line is the <a alt="[Picture of Magicom Phones]" href="http://www.xyz.com/products/magicom.html"><img src="http://www.xyz.com/products/images/magicom.gif" /></a>, the world's smallest portable pocket phone.

which yields:

The newest product in our line is the Magicom portable phone, [Picture of Magicom Phones] the world’s smallest portable pocket phone.

1. Database-based pages: Another higher-tech approach is to create a database-based server that creates HTML pages on the fly as the user asks for them. In this manner, the pages can be constructed with or without graphics as desired by the user. An example of this is the CommerceNet server.
2. Filter approach (alt page) This approach is similar to Approach 3, but involves the use of a filter/translator that would exist on the server as a common gateway interface. Pages would be constructed as described in Approach 2 above and, at the direction of the user, translated into either graphic or pure text pages on the fly. This approach has several disadvantages however. Since all pages must be processed on the fly, there may be a performance hit unless the filter program is used offline to create the text versions of the pages in advance. Secondly, this approach would only work for pages on the server with the AltPage cgi. Whenever references were made to other pages on other servers, the filter would not work. Image Maps on other servers would be a particular problem. Finally, such a filter would create text versions of pages, but since it would do it by formula, the pages may not be laid out very well or be very easy to interpret. Building access into the page or providing alternate pages which are laid out to make sense in text form (and to provide a text alternative to any Image Maps) would be much more effective.

SEPARATE VIEWER-BASED GRAPHIC ELEMENTS, PICTURES, AND DIAGRAMS

The problem:

Often in viewing HTML pages, users will encounter images or anchor phrases which will fetch and display a large graphic image. This image is displayed using a separate viewer in a separate window on screen.

If you cannot see, you have no access to this information.

If you are on a slow network connection, you need to wait a long time to download the image to see whether or not you are interested in the information it contains.

Solution strategies in the future

Someday, all graphic data formats will also allow incorporation of text describing the image (very useful for access and for searching or indexing pictures). Viewers will then allow display of the graphic, its text, or both. Servers will also be able to send the graphic portion, the text version, or both, on request from the browser.

Solutions today:

Until this occurs, however, the only known approach is to provide an alternate data file with the text description of the graphic in it. (Although some graphic storage formats do allow storage of text within the data structure, the servers, browsers, and viewers do not yet allow access to it.)

In general, Approach 2-1 is preferred, since many users may have asked for the text-only version because of speed, and may want to view occasional pictures of interest. Also, even blind users may sometimes want to pull up a picture to show someone, or to have someone describe it to them in more detail. Both of these are much easier with approach 2-1 than with 2-2.

AUDIO CLIPS

The problem:

Solution strategies in the future

The problems and solution strategies for audio clips are very similar to those for separate viewer-based graphic elements and movies:

Solutions today: The solutions strategies for accessing sound today also look essentially the same as for graphic files:

Access is provided by having a separate file with a transcript of the speech or description of the sound. This separate file is accessed in one of two ways:

Recommended Approach: Place an anchor to a page with a text transcript or description of the sound right next to the anchor for the sound.

(Generally not recommended) If the user has requested a text page only, replace all URL references to sound with URL references to the text transcript or description.

As before, Approach 1 is preferred because it provides the user with more options, allows them to use any residual hearing, and is useful to people with language impairments. It is often the case that people without disabilities are interested in the text transcripts as well.

MOVIES

The only known way to make movies 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 audio 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.)

Video: 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.

Solution strategies in the future

Eventually, all data structures should allow captions and audio or text descriptions of movies to be embedded in the data storage and transport formats. Servers should allow any combination of video, audio, caption, or description to be fetched on command.

Viewers or players should allow users to specify and display any combination of the above.

Solutions today:

Captions:

Where the viewers which are available which will display captions, captions can be embedded in the data structure for the movie.

A strategy which works for all 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.

Descriptive Video:

At the present time, the only known approach would be to have an alternate form of the movie with the descriptive narration included in the audio track.

IMAGE MAPS

Problem:

Image Map is a strategy that allows a user to click on different parts of a picture to reference different WWW pages. Clearly, this type of feature is completely inaccessible to people who are blind. They don’t know what the picture is, and don’t know where to click even if the picture is described. Image Maps are used in a wide variety of ways. Some uses are rather simple like using it to create nicer looking menu bars. Others are more sophisticated, like graphic representations of maps, diagrams, etc.

Solution strategies in the future

Strategies are being discussed which would have HTML pages include not only a URL for the Image Map’s picture but also a complete listing of all of the URLs associated with the Image Map. If descriptions are provided with the URLs, then browsers can be designed which would give a user the choice between the graphic Image Map or a descriptive listing of the choices normally provided by the Image Map in all text format.

Solutions today

Today, there are three strategies for providing access. All of them involve ways to provide an option for a text-only version of the Image Map’s choices, usually as a text listing of choices.

FORMS

Problem:

Some HTML pages include forms constructs. At the present time it is difficult for screen readers to access some forms elements. Further research is being conducted in this area.

Solution strategies in the future

In the future, features within the browsers will allow users to display forms elements in a way that screen readers can access them.

Solutions today

For now the best idea would be to provide alternate mechanisms for accomplishing forms functions.

SPECIALLY FORMATTED DOCUMENTS

Problem:

As HTML evolves, new flexibility is being introduced. Tables and other constructs allow text to be laid out in side by side paragraphs and other formats which cause difficulties for screen readers.

Solution strategies

CUSTOM DATA STRUCTURES AND VIEWERS

Background: Some web sites are introducing special data structures and viewers to differentiate themselves or provide special functions not available with the standard tools.

Access Strategies

The only way for these custom data and views to be accessible is if the access is built directly into the viewer. Standard access tools do not generally work with special viewers.