January/February 2003 // Commentary
Making Online Information Accessible to Students with Disabilities, Part II
by Janna Siegel Robertson and James Wallace Harris
Note: This article was originally published in The Technology Source (http://ts.mivu.org/) as: Janna Siegel Robertson and James Wallace Harris "Making Online Information Accessible to Students with Disabilities, Part II" The Technology Source, January/February 2003. Available online at http://ts.mivu.org/default.asp?show=article&id=1034. The article is reprinted here with permission of the publisher.

Internet access and usage for individuals with disabilities is a growing problem in the field of instructional technology. Approximately 10% of American adults have a severe disability that requires assistance in their performance of daily activities (McNeil, 1997). In terms of visual impairments alone, 80 million people suffer from potentially blinding eye disease, 11.4 million people have visual conditions not correctable by glasses, and 1.1 million are legally blind (University of Washington Department of Ophthalmology, 2000). To address the concerns and issues of Americans with disabilities, Congress passed Section 508 of the 1998 Rehabilitation Act. Since then, additional Section 508 guidelines have been adopted to meet the needs of those who rely on assistive software devices in their use of information technology.

Though most people agree that the Internet should be accessible to users of assistive technology, many may be unaware of the technical understanding needed for providing equal access to Web pages and online instruction (Nielson, 2001). There are several assistive technology software and hardware devices used to access Web pages by individuals with disabilities (Alliance for Technology Access [ATA], 2001). Scanning software, for example, enables individuals with motor disabilities to click an alternative mouse, hit a switch, use their voice, or access an alternative keyboard when they are not able to use either a traditional mouse to "point and click" or a keyboard to tab through items. Audio-enhanced screen readers also use on-screen scanning software: the scanning software highlights each word or non-text item and reads it aloud, which helps individuals with visual impairments or reading disabilities. Consequently, most of the Section 508 accommodations promote Web page designs that allow on-screen scanning software to highlight each word, link, or graphic, one at a time.

A previous article in The Technology Source by the first author (Robertson, 2002) offers a preliminary overview of the Section 508 guidelines that were adopted in June 2001, and includes links to technical information for each guideline (see Exhibit 1). As a further resource for Web site developers and designers, this follow-up article focuses more closely on the major HTML coding techniques used when making Web pages and online courses accessible to students with disabilities. The following examples of accessibility features are not difficult for most Web authors to incorporate into their Web pages. With a few adaptations, Web page developers can make online information accessible to students with cognitive, sensory, or motor disabilities.

Graphics and Non-Text Items

According to the U.S. Access Board (2001), Section 508 specifies that Web developers should provide a text equivalent for every non-text element (e.g., in the HTML tags "alt" for "alternative text" or "longdesc" for "long description"). This guideline is helpful both for individuals with visual impairments and for those persons who do not use graphics due to attention difficulties. This text equivalent should describe the purpose of the graphic, image, or sound, and reiterate the text that accompanies it. For example, hold the cursor over the graphic in Figure 1 and the text designated by the "alt" tag will appear in some browsers. A screen reader will say the phrase. Exhibit 2 displays a sample HTML coding for the graphic in Figure 1 (all HTML coding for this article was done in lowercase as suggested by the World Wide Web Consortium [W3C, 2002]). The latest versions of several Web authoring tools (Dreamweaver, Netscape Composer, and Microsoft FrontPage) include a new prompt feature that enables users to add alternative text when they insert a non-text item. Identification of graphics can also be accomplished without HTML coding by including a textual description near the graphic (e.g., a caption to a photograph).

The rule for writing text descriptions for non-text elements is to ensure that the descriptions are accurate and useful. To give a graphic a generic alt tag of "logo" or "heading" is not informative. However, thorough descriptions can be equally distracting. For example, too much information for Figure 1 would be, "This heading says The University of Memphis written in white letters on a blue background. The logo of the university is located on the left-hand side and is a shield divided into four quadrants. There are four symbols, one in each quadrant." This is more information than is necessary for understanding. There are some exceptions, however, to these examples. An image linked to another page may require additional information (e.g., the URL). There are also times when a developer should give no information. Decorative items, such as arrows, buttons, spacers, or borders that contain no useful information, do not need to be read aloud to a person using a screen reader. In this case, rather than omitting the "alt" tag for these images (which makes the screen reader say the name of the image), the developer should use the same "alt" coding but leave it blank between the quotation marks. For more information about using alternative text, please see the National Cancer Institute 508 tutorial (2001).


Many Web designers use tables to format text, to create page layout, or to present data in a visual way. However, using tables may create havoc for screen readers. Imagine placing a ruler on the screen and reading from left edge to right, disregarding all layout. Screen readers scan textual data in a similar fashion, which can be very confusing to listeners with visual or cognitive difficulties. Taking this situation into account helps with the design of accessible pages. For example, the left-to-right scanning problem may be addressed by designing simple layouts or by linking to text-only pages. While text-only alternative pages may require significantly more work for the designer, this is not an issue for database-generated pages. Usually text-only pages are used as a last resort. More often, Web developers separate format from text by using a cascading style sheet (CSS—discussed below under "Color"). By having the format in a different file than the text, Web authors can still have interesting colorful layouts but not interfere with scanning software and screen readers. In either case, a more conscientious approach to formatting issues can promote greater access.

When creating data tables that can be understandable when read by screen readers, Web authors need to use HTML codes to identify row and column headings, and to associate cells with these headings. For example, see Table 1 as well as Exhibit 3, which provides the HTML coding of Table 1. The coding demonstrates how to associate table data ("td") with their corresponding table headers ("th"): the table header tag specifies headings associated with each data cell, and each table header cell must therefore have an identification ("id") attribute. Note that in one case, we have also incorporated the use of abbreviation ("abbr") for one of the headers ("Readings" instead of "Textbook and Other Readings") so that it is less repetitious for the student using a screen reader. A screen reader might read this table as shown in Exhibit 4. In contrast, without clear table header and cell coding, students using a screen reader might hear the text in Exhibit 5; users with visual or cognitive difficulties would be confused by this disorganized sequence of information. By incorporating proper table headings within the HTML code, Web developers can provide clear verbal prompts for users with audio-enhanced screen readers. Complete descriptions and examples of these and other coding options are available from the W3C (1999; 2000).

For graphics, graphs, scientific formulas, mathematical notations, and data tables, developers can use either "longdesc" attributes or descriptions. HTML has a "longdesc" option, but not all screen readers use this feature (Clark, 2000). The best solution is to insert a descriptive symbol (i.e., "D") in the appropriate place and link it to a text-only description of the item in question. For example, on the National Arts and Disability Center page, a "D" link appears underneath the icon at the top of the page; this link leads to a textual description of the icon that can be scanned by a screen reader.


Web developers can make Web information accessible for students who are color blind or need larger fonts by using cascading style sheets (CSS). A CSS controls presentation of the content and is extremely useful when creating several pages that use the same style. (For a complete discussion and tutorial on how to create CSS, please see the information at W3C CSS tutorial.) Users can configure their own browser to override standard layout with a customized layout, or Web developers can easily use a CSS format to create alternate pages with enlarged fonts, less distractive colors, or simplified layouts. Exhibit 6 gives an example of how a student using an alternative CSS would view Table 1; Exhibit 7 provides the coding involved in making the CSS shown in Exhibit 6. The main rule for accommodating style sheets is to make the information and formatting separate. The style sheet controls all layout and font information using HTML commands, whereas the text is left plain. Separation of information from format helps when making printer-ready pages, which are usually very friendly to accessibility tools.

Color usage is of particular concern for individuals with color blindness. There are helpful Web sites from Lighthouse, VisiBone, and the MSDN library that discuss the types of color blindness and the colors not to use; Visucheck will allow one to check out an existing page to see how it would been viewed by a person with color blindness. However, we find that a Web page with good contrast helps viewers with any type of visual impairment. The color combination of black on white still works best for most cases, but other dark colors on very light backgrounds work almost as well. The opposite (light colors on a dark background) may work fine, but such an arrangement can cause problems if the font color is embedded into the HTML coding. Users cannot change embedded colors, and the colors will not work if (a) users have turned off their colors or (b) if they are using a browser that does not support color (such as in hand-held devices). Thus, the style sheet should control the colors. (See Exhibit 6 for a CSS example that enlarges Table 1 and changes the color contrast; see Exhibit 7 for an illustration of how the HTML code of the style sheet controls these colors.) For individuals new to HTML coding, the rgb (red, green, blue) color codes can be found at such online sites as HTMLGoodies, VisiBone, and Webmonkey.


Developers commonly use forms to create online exams. These forms can be confusing to students using scanning software and/or screen readers that read from left to right if the information is above each form field. An easy solution is to provide the information to the right or left of the form field. Figure 2 illustrates a poor example of a form. Scanning software or a screen reader would scan Figure 2 as, "Name, Phone, E-mail, input field, input field, input field." This information would be difficult for a person with a visual impairment or a motor difficulty to access; the sequence of prompts and input fields do not clearly alternate. If the form was longer, it would be even more disorienting to the listener and impossible to fill out correctly. Figure 3 shows a good example of using form fields where the information prompt is read before the input space is provided.

For multiple-choice questions, accommodations are not necessary since they are traditionally written with the selection to the left of the choice. Essay questions also pose few problems since there is a large space provided after the question by the "textarea" tag.

Skipping Navigation Links and Menus

Even when authors avoid using frames for navigation menus, they often repeat links on each page for usability. This setup creates problems for individuals with visual or motor impairments using scanning software because they have to wait while the program tabs through each link on a page. Developers can help users with disabilities overcome this problem by embedding anchors to allow these individuals to skip menu links. A "Skip Navigation" link performs the desired function and can be made visible or invisible, depending upon the situtation and the author's preference. The HTML code is fairly simple for designers who allow the skip link to jump past the menu, which enables users to continue with their reading. This option is best accomplished if the links are grouped together using the "map" attribute, even if there is no actual image map. The following sites illustrate this technique. WebAim has "Skip Navigation" visible at the top of each of its pages. In contrast, the W3C WAI pages have an invisible "Skip Navigation" link that is only visible if a user views the page source or uses a text browser with scanning. See Exhibit 8 for an example of the HTML coding used for a "Skip Navigation" link and the "map" attribute. This example shows a visible link; to make it invisible a developer needs only to match the link text color to the background color, or use a transparent graphics interchange format (GIF) file in its place.

Usability and Accessibility

There is a faction of Web authors who believe simplicity is the best measure for increased usability (Ihnatko, 2002). These authors will typically avoid using animations, plug-ins, image maps, time delays, or multimedia unless there is no other way to accomplish the task. The "king of usability," Jakob Nielson (Gilmour, 2001), also provides useful information on how to organize and write text for online reading (Nielson, 1997a). Nielson believes that pages should load in a second or less and be accessible to individuals with older computers and browsers, non-graphical browsers, and hand-held devices (Nielson, 1997). Fortunately, this approach to design fits in well with accessibility, since the same features that make a Web page usable often make it accessible (Nielson, 2001b). For more information on usability and Nielson's philosophy, see his Web site at Useit.com.

Supporters of simplicity for usability may not agree with the suggestions we have made for graphics, data tables, and forms since some developers may consider these suggestions unnecessary. But as authors of online courses and educational information, we found there were situations where it was best to use some non-text displays to convey information. Exhibit 1 has more information on how to make the features not discussed in this article accessible. To check a Web site for accessibility, authors can use online accessibility evaluation tools such as Bobby or 508 Diamond Tools.


Authors creating Web pages for online courses and information need to make them accessible to students with cognitive, motor, and sensory disabilities. Though the Section 508 guidelines are only mandatory for federal agencies, the philosophy of making the Internet accessible should inspire all Web authors. Publishers of Web authoring tools are currently working to make these accommodations easier to implement. The Authoring Tool Accessibility Guidelines 1.0 and the User Agent Accessibility Guidelines 1.0 developed by the World Wide Web Consortium (W3C) should help with accessibility issues if adopted by publishers. In particular, Section 508 developers have included guidelines for animations and frames with the intent to encourage these features to become more accessible in the future. These techniques for making graphics, data tables, format, color, and navigation links usable are not difficult to accomplish, and they may make a significant difference in the lives of individuals with disabilities.


Alliance for Technology Access (2001). Product descriptions: Alternate input. In Computer and web resources for people with disabilities (part 2, chap. 4). Retrieved July 29, 2002, from http://www.ataccess.org/resources/atabook/s02/s02-03a.html

Clark, J. (2002). The glorious people's myth of standards compliance. Retrieved July 29, 2002, from http://www.joeclark.org/glorious.html

Gilmour, K. (2001, August). The future is bright. Internet Magazine. Retrieved July 29, 2002, from http://www.internet-magazine.com/features/jakob1.asp

Ihnatko, A. (2002). Who says design should be simple? Newmedia. Retrieved July 23, 2002, from http://www.newmedia.com/nm-ns.asp?articleID=2275

McNeil, J. M. (1997). Disabilities affect one-fifth of all Americans: Proportion could increase in coming decades. Census Brief 97(5). Washington, DC: U.S. Department of Commerce. Retrieved July 23, 2002, from http://www.census.gov/prod/3/97pubs/cenbr975.pdf

Nielson, J. (1997a, October). How users read on the Web. Alertbox . Retrieved July 23, 2002, from http://www.useit.com/alertbox/9710a.html

Nielson, J. (1997b, March). The need for speed. Alertbox. Retrieved July 23, 2002, from http://www.useit.com/alertbox/9703a.html

Nielson, J. (2001, November). Beyond accessibility: Treating users with disabilities as people. Alertbox. Retrieved March 17, 2002, from http://www.useit.com/alertbox/20011111.html

Robertson, J. S. (2002, July/August). Making online information accessible to students with disabilities. The Technology Source. Retrieved March 17, 2002, from http://technologysource.org/?view=article&id=196

U.S. Access Board. (2001). Section 508: Scope. Retrieved July 23, 2002, from http://www.access-board.gov/sec508/guide/scope.htm

University of Washington Department of Ophthalmology. (2000). Statistics on blindness and blinding disease in the United States. Retrieved December 13, 2002, from http://depts.washington.edu/ophthweb/statistics.html

World Wide Web Consortium (W3C). (1999). 11.4. Table rendering by non-visual user agents. Retrieved July 23, 2002, from http://www.w3.org/TR/REC-html40/struct/tables.html#h-11.4

World Wide Web Consortium (W3C). (2000). 5.1. Tables of data. Retrieved July 23, 2002, from http://www.w3.org/TR/WCAG10-HTML-TECHS/#data-tables

World Wide Web Consortium (W3C). (2002). Hypertext markup language homepage . Retrieved July 23, 2002, from http://www.w3.org/MarkUp/

platform gamesbrain teaser gamestime management gamespc game downloadsbrick busterhidden objects games
View Related Articles >