DESIGN OF HTML PAGES TO INCREASE THEIR ACCESSIBILITY TO USERS WITH DISABILITIES STRATEGIES FOR TODAY AND TOMORROW VERSION 6.6 4/5/96 Gregg C. Vanderheiden Ph.D. Wendy A. Chisholm Neal Ewers 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. (This is a living document. Comments and suggestions are solicited. web-team@trace.wisc.edu) HTML QUICK REFERENCE PAGE April 1996 - Gregg C Vanderheiden Ph.D., Wendy A. Chisholm, Neal Ewers This page provides a quick reference of the ideas you should consider while designing HTML2.0 pages to maximize the number of users that can view then TODAY. This includes people with text-based browsers, people with slow (modem) connections, people without A/V capabilities, people with helper applications missing, and people with disabilities. The goal is to make pages accessible while maintaining or increasing their attractiveness. Several strategies are suggested for each area to allow you to select a strategy or combination of strategies that match your needs. TEXT ANCHORS 1) Make text anchors descriptive enough so that they make sense when read out of context. 2) Place a dividing character between links which occur consecutively. Vertical bars are often used to prevent a list of links from being read as one link by a screen reader. GIF and other IN LINE GRAPHICS 1) Provide an alternate text description ( ALT-TEXT ). This includes all graphics - even decorative ones. Otherwise, the user with a text-based browser sees a note saying there is a graphic but doesn't know what it is. 2) Include a text anchor to a page describing the graphic ( recommend a capital "D" or a short phrase located next to the picture) which takes you to a separate page with a full description of significant graphic elements, pictures etc. 3) Provide an alternate text-only page which translates all of the graphic and text information into text only. This can provide a fast access method for all users. You may have text-only pages for just troublesome pages or all pages at your site. Users should be able to switch back and forth between text-only and graphic versions of the page. Style suggestions: ( Make your ALT-TEXT descriptions short and functional. ( For bullets use a lower case "o" as the ALT-TEXT. ( For horizontal rules use the words "horizontal line" as the ALT-TEXT. JPEG and other EXTERNAL VIEWER GRAPHICS Three alternate strategies which can also be used together. 1) Include a text anchor to a page describing the graphic ( Recommend a capital "D" or short phrase located next to a thumbnail picture) which takes you to a separate page with a full description of graphic elements, pictures etc. 2) Provide an alternate text-only page which translates all of the graphic and text information into text only. This can provide a fast access method for all users. You may have text-only pages for just troublesome pages or all pages at your site. Users should be able to switch back and forth between text-only and graphic versions of the page. Note: It is possible to embed text descriptions in some picture formats such as JPEG. Someday, external viewers will be available which allow you to view either the picture or the description from such formats - if the text description is there. It is a good idea to include it now - but it is not sufficient for access yet. AUDIO CLIPS Maintain a link to a page with a transcript or description of the sound file. Use a phrase such as "or a transcript of xxxx" or "hear the speech or read the transcript" with "read the transcript" acting as the link to the transcript. Note: Someday audio file formats and players may include the ability to handle text as part of the sound file. MOVIES 1) Include Caption or Text Tracks with a description of the sounds and words of the movie. Quicktime for example allows text tracks which can be viewed at the user's discretion 2) Include an alternate sound track which includes an audio description of the video mixed with the regular audio track. (If your movie format does not support alternate audio tracks then you can provide a second copy of the movie "with audio description" included) 3) Provide an alternate text file with a description of the movie and a transcript of the audio. Note: If the movie format permits multiple video tracks then a secondary video track with an interpreter signing American Sign Language could also be provided. IMAGE MAPS 1) Provide text anchors for all links accessible through an image map. Usually provide by a list of text anchors just below the Image Map. 2) Provide an alternate text-only page which translates all of the graphic and text information into text only. This can provide a fast access method for all users. Users should be able to switch back and forth between text-only and graphic versions of the page. Note: Client side image maps are rapidly coming to the fore. As soon as a standard is defined and text-based browsers (and non-image modes of graphic browsers) support them this will be another solution strategy. (Text descriptions for each URL in the client side image map will be required.) FORMS 1) Provide a form which can be downloaded then mailed or e- mailed, or a phone number someone can call to provide the requested information. Note: To make edit boxes accessible by users viewing pages with screen readers, some sites are experimenting with place- holding information in edit boxes, like short descriptions or cues, so that screen readers can detect the presence of the edit boxes. TABLES Tables cause problems for screen reading software (used by people who are blind) since the screen readers 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. No good solutions exist at this time. If you can avoid using the TABLE structure that is best. You could also present the data on an alternate text page without tables. Work is in process on this problem. NON-STANDARD PAGE AND DOCUMENT FORMATS 1) Avoid non-standard HTML formats, special tags etc. They often cause problems for Braille translation, screen readers and some browsers. OR Provide an alternate text-only page which translates all of the information included in the original page to text only. This can provide a fast access method for all users. Users should be able to switch back and forth between text- only and graphic versions of the page. 2) Always provide HTML, or at least ASCII forms, of all documents presented in PDF, PS, WORD or other formats. CUSTOM DATA STRUCTURES AND VIEWERS Avoid non-standard data structures and viewers. The only way for 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. COLOR 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. 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 in black and white. TESTING Always test your pages using a variety of text browsers and platforms (PC, MAC, UNIX). Be sure to include text-based browsers and use graphic browsers with images turned off. OVERVIEW When discussing the accessibility of the World Wide Web, it is important to break the problem down into the three basic components: - the source material, - the pipeline, and - the viewer. Making the WEB accessible or usable by people with disabilities involves all three components. Some things need to be done when the source material is created. There are things that can be done at the pipeline stage, and there are things to be done in the browsers or viewers. This document focuses on things that can be done when creating HTML pages (source documents), but also mentions strategies that might be used at other levels now or in the future to provide context and a look forward. In some cases, problems which are dificult to address today at the source document level may be easily addressed with changes in the pipeline or viewers. Making HTML Documents Accessible TODAY There are some features of the World Wide Web (WWW) which are not currently accessible to people with some disabilities using today's browsers (such as Mosaic, Netscape, Microsoft's Internet Explorer, AOL net browser etc.). 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 WWW browsers, 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 are 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 WWW (HTML) documents that are accessible by simply avoiding the aspects of HTML or WWW browsers 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 HTML, it is nonetheless a viable approach, as is using gopher and ftp. However, a WWW/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 viewers such as Mosaic. - Other strategies, however, do not require any changes and can be used today. Below are some of the strategies from both categories. Organization of this document Problems in access to HTML fall into seven 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) Tables; 8) Non-standard page and document formats; 9) Custom data structures and viewers; 10) Color. 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, Netscape, W3, etc. This is then followed by things that can be done to make HTML pages available today. 1) IN-LINE (GIF etc.) GRAPHIC ELEMENTS, PICTURES, AND DIAGRAMS 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 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. 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. Solution Strategies 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 an option within the IMG definition and allows authors to attach an alternate text description to any in-line graphic. It is commonly referred to as ALT-TEXT. The form for this is:

The latest versions of Mosaic and Netscape support this strategy as do the text-based browsers like Lynx and DOSLynx (whose developers at the University of Kansas introduced this convention). In the future it is probable that most or all graphic browsers will also support this feature. This approach does not actually allow text descriptions to be included (and called up separately from) the picture data file, and it does not address the problem for graphics which are NOT embedded in the text (which is covered in the next section). It does however provide a mechanism for attaching text descriptions to in -line graphics (pictures that are disaplayed as part of the HTML page. The ALT-TEXT approach is very effective in most layouts - and is recommended for all in line graphics. However, on some pages with unusual layouts, it may result in pages which are confusing. In this case it is recommended that you ALSO create a separate "text only" version of the page which eliminates the use of graphics. In general, however, this makes it a bit more complicated to maintain your pages since edits must always be done to two pages when edits are needed. (If your pages are generated from a database "on the fly" this problem would not exist - but your page generation software would need to include this capability) Today, therefore, you can/should use one of these five approaches. A combination of the first 3 approaches is probably the most effective: Approach 1-1: ALT-TEXT: Provide an ALT-TEXT tag which would be displayed instead of the graphic or picture when the picture is not displayed (e.g. when viewing page with a text only browser, or with the "show/load pictures" feature turned off. (See above for format) [See also Picture Description Below] Approach 1-2: Description page By their nature, ALT-TEXT descriptions are usually short and define the basic purpost of graphic elements. For example "Logo for XYZ company" or "Picture of ZZZ Center Building". These are instructive but do not provide very much information about the pictures. In order to allow people who are blind with additional information WGBH has pioneered the practice of placing a capital "D" next to any pictures or graphics which acts as a small Anchor to a longer description of the graphic. For example, "The Logo for XYZ company consists of a globe with people of different races all standing out from the globe holding hands while a sunburst shines from behind the earth. The earth is positioned so that no particular continent is centered on the globe" Descriptions which are too long for ALT-TEXT descriptions can thus be provided... yet do not clutter up the main page. Since the "D-tag" is not a very descriptive link, if you use this method you should probably include a statement somewhere that describes what access features you have included so that people know that a captial "D" will take them to a description of an image. Another option is to use a more descriptive text anchor, such as "or a description of xxxx". Approach 1-3: 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. If this is done 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. It is still recommended that you provide the ALT-TEXT tags described in approach 1-1 on your 'graphic version' of the page. It is easy to see that creating text-only versions of every page on a site doubles the number of pages that need to be maintained. Here are three methods for generating and maintaining text-only pages. Method 1-3.1: "By hand" Sometimes, a site may only need to create text-only pages for layouts that can not be made accessible. This may only involve a couple of pages. Method 1-3.2: Database-based pages: Create a database-based server that generates HTML pages on demand when the user asks for them. In this manner, the pages can be constructed on the fly either with or without graphics as desired by the user. An example of this is the CommerceNet server. There are now a number of software products designed to do this. This is more computationally intensive than a normal server but the pages that change seldom could be rebuilt and stored periodically to reduce this. Method 1-3.3: Filter This approach is similar to Method 1-3.2, but involves the use of a filter/translator that would exist on the server as a common gateway interface (cgi). Pages would be constructed using ALT-TEXT and alternate text pages where needed and, at the direction of the user, translated into either graphic or pure text pages on the fly. This method has disadvantages however. Since all pages must be processed on the fly (as with the databased method), there may be a performance hit unless the filter program is used off-line to create the text versions of the pages in advance. Secondly, this method 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 unless client side image maps were used. 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) as with Method 1-3.1 would be much more effective. Approach 1-4: 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. The format would be: Recommended format today: Running text on the page Text describing picture.

running text that could serve as an anchor instead of or in addition to the in-line picturerest of running text.... An example: The newest product in our line is the Magicom portable phone, 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 , 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. 2) 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 often 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. If you do not have the proper helper programs you can not see the information. Solution strategies in the future Someday, all graphic data formats (such as TIFF, JPEG, PICT or their successors) will also allow incorporation of text describing the image (very useful for access and for searching or indexing pictures). External or "Helper" viewers could then allow display of the graphic, its text, or both. Servers could also be able to send the graphic portion, the text version, or both, on request from the browser. (Java applets could be programmed to do this today but it is not a general capability yet.) Solutions today Until this occurs, however, the only known approach for providing alternate text for NON-EMBEDDED GRAPHICS 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.) Approach 2-1: (generally recommended) Place an anchor to a separate page which has a text description of the picture right next to the anchor that pulls up the picture. As discussed in the last section, WGBH has instituted the practice of putting a captial "D" next to pictures or graphics in a document. If you are using a thumbnail version of the picture as an anchor to the larger picture, you could use the "D" very effectively for the anchor to the description for the picture. Approach 2-2: Include a descriptive text anchor to a page describing the graphic. For example: "or a description of xxxx". Approach 2-3: If the user has requested a text-only page, replace all references to pictures with references to the text files describing them. 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-3. 3) AUDIO CLIPS The problem: People who are deaf cannot access information which is presented in auditory form only. People without audio capabilities in their computer also may not have access. People who do not have the proper Audio Player Helper application may not be able to play the audio clip People in noisy environments may not be able to hear information presented auditorially. Solution strategies in the future The problems and solution strategies for audio clips are very similar to those for separate viewer-based graphic elements (Problem Area 2) and movies (Problem Area 4): They all use separate players or viewers/windows to present the content. Access in the future can be accomplished by allowing text to be stored in the data structure. Servers should be able to send the sound form, the text form, or both, on request from the browser. Players should be able to present the sound format, the text format, or both formats. RealAudio or similar formats should include the ability to simultaneously present the text version of the audio information. 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: Approach 3-1: (generally recommended) Place an anchor to a page with a text transcript or description of the sound right next to the anchor for the sound. Approach 3-2: 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 3-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. Example: Below is an example based on the White House Web server, courtesy of Paul Fontaine at the General Services Administration. Note that this example includes both ALT- TEXT access to the sound icon (audio.gif) (for users who are using text browsers or screen readers) and the text translation (al npr intro.html) of the audio file (gore.au) (for users who cannot hear or do not have audio capabilities on their computers). Suggested code: The President asked Vice President Gore to head up the National Performance Review (NPR) [Sound
Icon]

hear or read Mr. Gore's speech introducing NPR. This would look like: The President asked [Picture of Al Gore] Vice President Gore to head up the National Performance Review (NPR) a project to make government work better and cost less. You can [Sound Icon] hear Mr. Gore's speech introducing NPR or read a transcript.. 4) 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 video 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. Text transcripts should be provided for both Audio and Video for users with text-based browsers and/or no helper apps. 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 (helper applications) should allow users to specify and display any combination of the above. Solutions today Captions (for those who do not have access to sound) Approach 4-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 for the movie. Approach 4-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. Approach 4-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 cannot see the video portion of the movie) Approach 4-4: If the movie format allows alternate audio tracks (e.g.Quicktime) you can provide an alternate track which includes the descriptive narration. Approach 4-5: If your movie format does not, you can provide an alternate form of the movie with the descriptive narration included in the audio track. Approach 4-6: 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. Example - Quicktime In Quicktime you can add as many Audio or Video Tracks as you wish. The user can then select as few or many of the tracks as desired when they view the Quicktime Clip. Tracks could include - The regular Video Track - The regular Audio Track - A text Tract with captions - An Audio Tract with Video Descriptions Added - An additional Video Tract with American Sign Language Translation - Additional Text or Audio or Video Tracts to provide other languages Other Advantages In addition to the access advantages of these approaches, there are also other benefits as well. - Movies with captions can be indexed based on their captions and found using text searches of the net. - You can search for words within the captions of a movie and jump to that position in the movie. - If descriptions are provided in text mode as well, you can index and search for any VIDEO information which is contained in the descriptions. 5) 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. 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. 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 "Client Side" image map capabilities are beginning to be introduced in browsers though no standard approach has yet been agreed upon. "Client Side" image maps are similar to regular image maps except that the information regarding all of the links or "hot spots" on the image are sent to the browser along with the image map picture. If descriptions (a sort of "ALT-TEXT" for the Image Maps links) 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. Approach 5-1: Next to (or just below) the Image Map graphic, provide a text anchor which will take you to a new page with the text listing of the Image Map URLs on it. This is easy, but removes the listing from the context of the rest of the page. As a result this approach is not generally recommended. Approach 5-2: (recommended) Have an option for a text-only page which presents an alternate form of the entire page which replaces the Image Map with a text listing of the Image-Map URLs which is optimized to work logically within the layout of the page. Approach 5-3: (also good if done in a way which avoids confusion) Provide the listing of Image Map choices as a text list immediately below the Image Map. This sometimes works, but can also be confusing. If used, ALT-TEXT provided with the IMAGE-MAP should say that the information in the IMAGE-MAP is provided in the choices below it. See appendix for experimental approaches and discussion. 6) FORMS Problem: Some HTML pages include forms constructs. At the present time it is difficult for screen readers and some browsers to handle 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 a form which can be downloaded then mailed or e-mailed, or a phone number someone can call to provide the requested information. To make edit boxes accessible by users viewing pages with screen readers, some sites are experimenting with place holding information in edit boxes, like short descriptions or cues, so that screen readers can detect the presence of the edit boxes. (Additional, more specific information on both the problems and strategies for different browsers will follow for this area.) 7) TABLES Problem: Tables cause problems for screen reading software (used by people who are blind) since the screen readers 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 in the future It has been proposed that the table construct will contain two attributes that will help people using screen readers access information in tables. These are the AXES and AXIS attributes that would be associated with each cell in the table. Thus for each entry in the table the row and column information as long as the cells data contents would be available to the screen reader. Solutions today No good solutions exist at this time. If you can aviod using the TABLE structure that is best. You could also present the data on an alternate text page without tables. Work is in process on this problem. 8) NON-STANDARD PAGE AND DOCUMENT FORMATS 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 which will usually read a row in a table as a sentence. For Microsoft Windows, browsers could be designed to use child windows for each place in the table, and render into the child windows. Doing this would allow screen readers to interpret the page layout and develop techniques to navigate through the table heirarchy. Solution strategies for today 8-1: Keep layouts simple and straightforward 8-2: Avoid side by side presentation of text 8-3: Avoid using graphics to provide organization or structure to the document. Use HTML. 8-4: Where following guidelines 8-1 to 8-3 would interfere with the presentation of the information for some reason, a text-only page which presents the same information in an accessible format could be used. 9) CUSTOM DATA STRUCTURES AND VIEWERS Problem: Some web sites are introducing special data structures and viewers to differentiate themselves or provide special functions not available with the standard tools. Solution 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 at this time. 10) COLOR Problem: Back ground graphics, text colors and colorful images are being used fairly frequently in the design of web pages. Although this may make the page appear more attractive or memorable to some, to others it is not readable. Solution Strategies 10-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. 10-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 in black and white. THANKS TO Paul Fontaine, Paul Wilson, Peter Korn, Mike Paciello, Chuck Letourneau, WGBH and Pat Powers for their input and contribution to these guidelines. Appendix A Summary of the recent changes to Mosaic to facilitate operation by people with various disabilities (prepared by the Mosaic Access Group) 1) Implemented on the Mac and Windows platforms the display of ALT (text) tags on IMGs whenever alto-load of images is turned off. (Also benefits the "bandwidth impaired".) 2) Provided the ability to control font selection and size for all HTML text types on both the Mac and Windows platforms. 3) Provided the ability to control background color from the entire spectrum and intensity range for both the Mac and Windows platforms. 4) Provided the ability to control font colors for all HTML text types on both the Mac (whole-spectrum, all intensities) and Windows (16 color choices). 5) Provided the ability to completely change the default rendering instructions for both the Mac (by launching Mosaic via double-clicking on any of a set of Preference files you've built for yourself) and Windows (by commanding the use of a different file to fulfill the role of "Mosaic.ini") platforms. This will allow reasonable sharing of a physical machine by, say, someone with visual impairments and others without those impairments. The user with the disability will not have to item-by-item reconfigure the Browser each time it is to be used. 6) Implemented on the Windows platform the use of the left and right arrow keys as a means of navigation to the next adjacent hyperlink. Further, the user has a choice of 3 ways to indicate which anchor is "current" (i.e., will be fetched if RETURN is pressed), and one of these choices is a bordering box of any selectable color/intensity. 7) Added command icons to the Windows platform which are taken from the 'standard' Microsoft collection, hopefully facilitating interoperability with Screen Readers. 8) Added a series of audio-triggering events in Windows Mosaic. Upon one of these events occuring, Mosaic can now trigger a user-chosen, user-supplied audio file. Different audio files can be chosen for each supported event. 9) Continued to extend our bi-directional interface between Mosaic and sibling processes, to facilitate all forms of interactive augmentation, including (potentially) HTML-aware screen reader software. (We have provided the copyrighted Mosaic source code to at least 2 Universities recently who are working on such screen readers.) APPENDIX B EXPERIMENTAL SOLUTIONS AND DISCUSSION In the previous sections we have presented approaches that can be used to increase the accessibility of your HTML. There are several approaches that we are testing and soliciting input on that are not yet ready to be included in the guidelines. We include our current thoughts on these experimental approaches to generate discussion, ideas and solutions. The following section is divided into 3 categories: "D- tags," Text (alt-text and text anchors), and Forms and edit boxes. NOTES ON THE USE OF D-TAGS WGBH has pioneered the use of d-tags or "description tags" in order to describe the graphic image to which the tag is linked. These d-tag descriptions are longer and more descriptive that the definition afforded by alt-text. As many persons who have lost some or all of their vision wish to know more about the physical dimensions of the page, this is a real plus. The questions and comments below are designed to help develop a consistent policy on the use of these tags. With such a policy, users with text browsers and persons who use screen readers will be able to develop the same knowledge of the site as persons who are using graphical browsers. The well thought out use of d-tags will allow any user who is not seeing the graphic image to obtain quality information about the graphic or to simply proceed without it. These questions and comments were generated by looking at worse case scenarios. Often, the pages we used as models were image maps which were totally unrecognizable by the screen readers we used. The page containing these image maps also contained additional links. POSSIBLE STRATEGIES FOR THE USE OF D-TAGS D-TAG FORMATS 1. When the user clicks on a d-tag, they could be presented with the description of the image map as well as the links which could be followed from the image map itself. The question here is how best to deal with the fact that there may be links on the page containing the image map that are not reachable from the image map and thus cannot be accessed from the d-tag page. Does the user have to go back to the image map page and click on those links, or do we include, in the d-tag page, all the links which were on the original image map page? 2. When the user clicks on a d-tag, they could be presented with the description of the image map and all the links on that page even if they are not included in the image map. In this way, the user who wishes to understand the graphic image by reading the description would have the same access a sighted person would have on the image map page. He or she would be able to see all the links on the page at one time instead of having to toggle back and forth between the d-tag page and the original image map page. 3. The image map links and all other links on the page could be presented, by using alt-text and d-tags on the original image map or graphics page. This would also negate the need to toggle back and forth between this page and the d-tag page. Again, this would greatly clutter the graphics page. 4. The d-tag would include only a link which returned the user to the d-tag page. All other links would be accessed from the image map page. This would mean that the person who wanted a description of the image map would have to make a round trip to the d-tag page and back purely for the purpose of discovering the particulars about the visual properties of the image map. This would, however, decrease the amount of maintenance needed at the WEB site. 5. D-tags would not appear on the image map page. Instead, each time you had a page that had a d-tag, a text version of that page would be presented as an alternative. The d-tag would appear on the text page. In one scenario, the d-tag would also have links, in the other, it would not. The problem here is that if you had to create a text version of an otherwise accessible page just to offer a d-tag to someone who wanted to know what the graphic looked like, you would be creating a lot of text pages which would not otherwise be needed. PRESERVING THE FEEL OF THE SITE 1. In instances where the d-tag will appear on the graphics or image map page, there will be a need to preserve the purity of that page by keeping the d-tag as unobtrusive as possible. Perhaps using a very small font which would still be readable by a screen reader is one way of doing this. Because certain screen readers have problems dealing with rapid font size changes, More research will be needed in this area. Perhaps, at some time in the future when it might be possible to have visually nested links, it would be possible to include the d-tag in the alt-text link. In this scenario, one would be able to click on the d-tag to get a image description or the alt-tag to follow the link within it. The beauty of this strategy is that when you have images turned on, you would see the graphics page without the clutter of the alt-text or the d-tag. 2. Maximizing the knowledge of the graphical image by thoughtfully labeling the alt-text would clarify a number of situations and also cut down on the number of times the d- tag has to be used. For example, if the graphic was that of a man hole cover with a symbol which the street repair crew understood as a "need to repair" symbol, the alt-text might say, "man hole cover with repair symbol." The graphic would be completely defined in the alt-text. Obviously complicated graphics cannot be dealt with in this manner, but a number of images would fall into this category. Because the graphic has been so well defined, any person, who does not have graphics turned on, would have a greater knowledge of whether they wanted to follow the link attached to the graphic. TEXT VERSIONS OF A PAGE OR AN ENTIRE SITE 1. Perhaps one reason for making a text version of a page is not simply it's inaccessibility, but the inability, in any other acceptable format, to present, to a person using a screen reader, all the information a sighted person would be able to see at one time on one page. 2. When the site developer createS a text version of a page, for whatever reason, d-tags would be included on this page? The problem here is that many people read text pages because of the ability to rapidly read the text without unwanted references to graphical information which they feel they do not need. If you put a d-tag on the text page, would you also have to include a symbol as a place holder for the graphic in order to allow the person who wanted to use the d- tag to know where the graphic appeared on the page. This would mean more clutter for those who only wanted to read the text? 3. When only some of the pages at a site are text versions, how does the user know if the link they follow from a text page is taking them to another text page or to a more graphical page? When many of the pages in the main graphical version of the site are accessible and only a small number of text pages are needed, the developer may wish to keep the continuity of the site by causing these text pages to have much the same feel of the rest of the site. In other words, instead of being purely text pages which offer the information without any reference to the graphical images on the corresponding graphical page, these text pages would maintain the symbols, d-tags if included, and other references to graphical images which appear on the original page. In this way, when the user follows a link from the text page and ends up on a page which is not a textual representation of a graphics page, it won't make any difference. All the pages will have the same feel. The question of when a site presents a text version of the entire site versus presenting text versions of only those pages which are the most difficult to access by persons using screen readers and/or text browsers is a subject which needs more investigation. CONCLUSION Because the use of d-tags in some of the scenarios we have presented here would greatly change both the nature of the site and the amount of work needed to maintain it, we need to have a better feel for the numbers of persons who would desire these tags, and how they could best meet the needs of different users. ALT-TEXT AND TEXT ANCHORS Problem: Screen readers will often read the alt-text of image anchors and/or text anchors as one link if there is no punctuation between them. For example: a menu bar at the bottom of a page made up of one image anchor and two text anchors. The alt-text of the image and the first text anchor are read as one.

"link2" "link3" Experimental solution: a space and a vertical bar on either side of the text anchors resolve the problem. This will also separate the links for visual users. Some authors use two vertical bars instead of just one. NOTE: adding JUST a space or JUST a vertical bar is not enough to solve the problem ALL of the time. In some instances one or the other might work, but together the screen reader software we are using has consistently paused between links. Other punctuation may work, but we tested with vertical bars because we felt it not only increased the accessibility by a screen reader but it separated the text visually as well. Example:

| "link2" | "link3" NOTICE that there is a space before and after each vertical bar. Problem: alt-text is sometimes centered vertically next to the image icon and thus read on a different line. Example: | "link1" |

| "link3" Would most likely be read: link2, link1, link3 Experimental solution: A possible strategy is to take the image out of the sentence and put it before or after the paragraph or sentence. Authors can turn images off and see the placement of the alt- text, but the words may wrap differently on different browsers depending on the width and text size that users have chosen. Problem: Sometimes when alt-text is included in a sentence it is hard to tell where the alt-text ends and the text of the paragraph that it is included in begins. Experimental solutions: Place a character before and after the alt-text string. For example an x. This will be read by all screen readers, but may make things MORE confusing. For example, if this were the alt-text of an image map, "x see links below x" the "x" could be confused with an entity. i.e. icon x, x distance of miles to go, etc. This also adds two syllables to each alt-text entry. Another alternative is a slash (/). This way a person using a screen reader could turn the correct level of punctutaiton on so that a slash will be read or turn it off if they do not wish to hear the begin and end of the alt-text. With some screen readers, no punctuation means NO punctuation and in order to hear the slash some punctuation needs to be turned on. However, this also means that point (.), comma (,), @, %, ^, &, \, # etc. will be read which can greatly increase the amount of time and energy it takes to read a page. Including pumctuation sometimes confuses the context of a sentence. For instance, "With some screen readers point no punctuation mean no punctuation point" Problem: If height and width are specified for an image, the alt-text might wrap. If there are several images in a row all whose alt-text have wrapped a person with a screen reader might not be able to read this at all since a screen reader will read across the page. For instance if the alt-text were, "TRACE logo" "TRACE documents", "TRACE calendar." And depending on how the images were sized, a screen reader could read this as: TRACE TRACE TRACE logo documents calendar. This also may make the alt-text unreadable for sighted people. Current solution: At this time, a text-only version seems to be the only solution, unless the author can find a way around using the height and width attributes of images or use them in such a way that the text will not wrap. This is almost impossible to test however because people will have selected different fonts and sizes to be displayed by their browser. EDIT BOXES AND FORMS Problem: Screen readers pass over edit boxes which are empty. The user has no way of knowing they are there. Even if they know, for example, that there is likely to be an edit box for entering a search query, it is difficult to place the mouse pointer on the edit box without sighted assistance. Experimental solutions: 1. Put a place holder in the edit box. * If this place holder is accidently erased by the user, the I-bar will still be present in that box and the user can find it again. * Care would have to be taken to make sure the place holder did not interfere with such things as E-mail addresses, search routines, etc. The worse case would be that the user might have to erase the place holder in an E- mail address box. An asterisk might work in a search conditions edit box in that it would simply act as a wild card and allow the user to type in whatever word or phrase they wanted to search for. 2. Place the label for the edit box in a prescribed place relative to the box itself, for example, to the left of the box. As long as either there is a place holder in the edit box or the I-bar is present, the user would be able to find the label and then move the mouse pointer 1 space to the left to locate the edit box. 3. Alternate strategies could be used to obtain and act on the information normally found in edit boxes. * A search routine could be presented in an alphabetic index as well as a key-word search. * The user could down-load an address form or simply an E- mail address which could be used to return the requested information. Page 631 - 4/5/96 Please send comments and suggestions to: web- team@trace.wisc.edu