Jonathan Bacon's Web Site

12345 College Blvd
Overland Park  KS  66210-1299
913-469-8500 extension 3530

 

Making Web Pages Accessible

Compiled by Jonathan Bacon, Johnson County Community College

For the Colleague to Colleague Faculty Forum at Kansas City Kansas Community College on Monday, September 25, 2000. With some updates: October 2008.

Imagine visiting your Web page with only your ears. That's how blind and visually impaired visitors experience your Web pages. Next, imagine exploring your Web site with only your eyes. That's how many deaf and hearing-impaired individuals experience your site. Have you considered how you would navigate your Web site with its many buttons and "click here" links if you had a mobility problem?

Ask yourself, if you were not a TAB (that is, a "temporarily able-bodied" person) what content would be inaccessible on your Web pages?

Accessibility for Blind and Visually Impaired

For blind and visually impaired individuals, one of the main tools used to access Web-distributed content is the screen reader.

A screen reader operates using several basic principles that are important for you to understand.

First, the software reads a Web page from top to bottom and left to right as it converts the text into synthesized speech. The practical application, is that when a screen reader encounters a table, it reads across each line without regard for column breaks. An easier way to visualize this process is to take a piece of paper or a ruler and lay it across the screen under the first line. The screen reader reads straight across. When the line is complete, the sheet of paper or ruler shifts down a line and the screen reader reads that line left to right, ignoring the fact that the text is laid out in multiple columns.

Second, a screen reader cannot automatically interpret or describe a graphic image, so it responds by saying "graphic." As an example, if four buttons are encountered along the top of a page, the screen reader would vocalize: "graphic, graphic, graphic, graphic."

Your Challenge is to make your site accessible for visually impaired users by presenting all content using text descriptions or in another form that can be read by a screen reader. You can use a variety of techniques to accomplish this. You can:

  1. Provide a text-only version of each page on your site. Since a screen reader begins reading at the top left corner of your Web page, that is the best location for the link to a text only version of your page. It is helpful if your text-only page is set to a large font size, though many partially sighted individuals will set their default font size larger automatically. You do not need to avoid placing images on the text-only version of your page, just be sure to place each image in between paragraphs and fully describe it (see alternative text next). Depending on the nature of your page's message, you may be able to place all graphics at the end of the document. With this approach, provide a warning where the text ends and state that only images follow. Try to provide identical information on your text-only page including all images, all text, all activities, and all contact information (such as your name, company name, street and email address).
  2. Use ALT tags or alternative text representations of all graphics on your page. To accomplish this in FrontPage 98, you can right-click on a image and when a pop-up menu appears, select the Image Properties option. (You can do the same thing by selecting an image and then pressing the Alt+Enter key combination) Once the Image Properties dialog box appears, click in the Text field in the Alternative Representations area of the dialog box. Next, type the text that describes the graphic. When finished entering the alternative text, click the OK button. Two things occur when you establish alternative text for an image. First, a screen reader reads the text rather than saying "graphic" or "image." Second, when the mouse pointer rests on the image, a pop-up label appears that is visible for sighted visitors to your page.
  3. All links on a single line should be preceded or followed by a line break. When you create a text-only navigation bar at the bottom of your page with several links on a single line, it can be confusing for the user of a screen reader to determine when one link ends and another begins. By placing the links in a table and including a line break after each link, a screen reader can read each link as if it appeared on a separate line. In FrontPage 98/2000, you press the Shift+Enter key combination to add a line break. If using a text editor (such as Simple Text or Notepad), you can add a line break by typing the <br> tag. The following figure demonstrates this technique. Each of the four links appears in a cell in a one row table. The entry in each cell ends with the <br> tag.
  4. All text links should be descriptive of the target site or page. For example, rather than say "click here" a link should be descriptive such as "More information is available on my personal home page at http://www.jccc.net/~jbacon" where the URL is the link.
  5. Avoid using dashes, equal signs and other keyboard characters to add borders to your pages. For a visitor using a screen reader, these extra borders sound like a rattling telegraph or tele-type machine. Use graphics with ALT tags to separate blocks of copy on your pages.
  6. Provide an audio track version of all text. An audio track provides an alternate method of delivering your content. There is one advantage to using an audio track rather than relying on a screen reader. The person visiting your site can hear the tone and inflection of your message rather than a synthesized version generated by the screen reader.
  7. If your audience is using an older screen reader, avoid using tables. Tables are often used for formatting and to easily display visual data, but be aware of how the text wraps (when using older screen readers) because the screen reader can turn your carefully constructed columns of information into a series of scrambled phrases...that do not mix and match properly. HTML (Hypertext Markup Language) documents are not written to force a specific page layout. For instance, the width of the browser's window determines when a line of text in a Web document wraps to the next line. The same principle holds true for text in a table. The cell width determines when a line of text wraps to the next line. Unless you fix the cell width (which is not supported in all browsers), a single line of text in a large browser window may wrap to 2-3 lines in a smaller browser window. Remember, older screen readers read the first line visible on the screen from left to right. It does not read the entire contents of the first cell in column 1 before proceeding to read the text in the first cell of column 2. JAWS version 3.5 automatically handles tables and will read the entire contents of a cell before proceeding to the next cell
  8. When possible, avoid using bulleted lists and instead use numbered lists. This enables the person using a screen reader to better track the content.
  9. Use audio narration to effectively describe animations, simulations, digital video and other media incorporated into your Web pages. Especially where simulations have been used to illustrate new concepts for sighted visitors, use narration to describe what the visually disabled visitor cannot see. Animation accompanied by narration can be very effective in explaining and visualizing new concepts for students.
  10. Do not use colors for your background and text that cannot be seen by individuals who are colorblind. If you are colorblind, have someone who is not colorblind double-check your pages for readability. If you always use black text on a white background or white text on black backgrounds, you won't have problems.
  11. Check the spelling of your article before posting it to the Web. Most HTML editors now include spelling checkers. If a word is misspelled, any visitor to your site may have trouble understanding what you mean as opposed to what you spelled. This problem is only accentuated for visitors using screen readers.

Accessibility for Deaf and Hearing Impaired

For deaf and hearing-impaired individuals, accessibility means providing full-text versions and full-text descriptions of all media elements included on your Web pages.

Your Challenge is to see your content without hearing it. For TABs, the greatest weakness is the assumption that everyone has multiple senses for absorbing information. Use the following techniques to make your pages accessible:

  1. If you include an audio narration as part of your Web page, be sure to include a link to a full-text transcript of the speech or narration. Generally, it is important to provide a word-for-word transcript as opposed to a summary--unless you only provide a summary for both hearing and hearing impaired visitors. Do not make an assumption that some information is less important to deaf or hearing impaired visitors. Provide access to the same content for all visitors to your site.
  2. If you use sound effects or musical tracks on your pages, include a description of those sound elements. This can be a challenge for a hearing person. Ask yourself "Why did I include this sound effect or musical track on my page?" "What does it contribute to the experience of visiting my Web page?" Use the answers to those questions to put into words the purpose and meaning of the audio.
  3. When using animation or digital video or other media with sound, include a text description. Again, this can be a challenge. Typically, you include an animation or simulation on your site because you have a message to convey. Animation accompanied by narration can be very effective in explaining and visualizing new concepts for students. The narration should be available in text form for readers with hearing disabilities.

Additional Suggestions (taken from www.CAST.org) include:

  1. Have all external links (to URLs outside your web site) open in a New Window.
  2. Include an index page with Index and Back to Index links on all pages.
  3. Include text versions of all tables.

In summary, best practices suggest that you should:

  1. Provide more than one representation of all content
  2. Provide more than one option when expressing content and providing user control
  3. Provide more than one option to engage and motivate your learner/visitor.

These same three objectives will serve not only individuals with disabilities but also learners with varied learning styles.

Help With Checking Your Web Pages

You don't have to "go it alone" when checking your Web pages for accessibility. Several sites exist that can assist with the review process.

The Web Page Backward Compatibility Viewer page at http://www.delorie.com/web/wpbcv.html is a nice tool that tests your pages for both accessibility and compatibility with older browsers. On this page, you can instruct the Viewer to remove or ignore tags for images, tables, ALT-less images, frames, fonts, blinking text, centered text, Java applets, JavaScript scripts and marquees. To view how your page is interpreted and read by a screen reader, enter the URL for your page in the field at the top of the page and then be sure to deselect all check boxes.

The World Wide Web Consortium (W3C) has an HTML Validation Service available at http://validator.w3.org/. This validation service checks HTML and XHTML documents for compliance with W3C HTML Recommendations and other HTML standards. To use the service, simply enter the URL for the page you want validated. Once you submit the URL, you'll see displayed a line-by-line list of validation results. Keep in mind that this service is geared to more than accessibility issues. Listed "errors" can range from lack of the BGCOLOR attribute in tables to undefined FONT elements to failure to include a DOCTYPE declaration. You can also run WebLint (a syntax and minimal style checker for HTML) at the same time by selecting the "Include WebLint Results" check box.

Another useful site for exploring web accessibility evaluation tools is the Evaluating Web Sites for Accessibility: Overview page hosted by the Web Accessibility Initiative at http://www.w3.org/WAI/eval/Overview.html. Be sure to check out their Web Accessibility Evaluation Tools List Search site at http://www.w3.org/WAI/ER/tools/.

Resources

Resources used as background for this document include: Mike Britten's Web-Ability column for Salon Magazine Online which is available at http://www.salonmagazine.com/21st/feature/1998/05/05feature.html.

Terry Sullivan and Krystyn Manning's Could Helen Keller Read Your Page? article for All Things Web which is available at http://www.pantos.org/atw/35412.html.

Web Content Accessibility Guidelines 1.0 (W3C Recommendation dated May 5, 1999) http://www.w3.org/TR/WAI-WEBCONTENT/

Web Content Accessibility Guidelines 1.0 Checklist http://www.w3.org/TR/WAI-WEBCONTENT/full-checklist.html

Also check out http://www.w3.org/WAI/GL/ where you’ll find the W3C WAI Page Author Guidelines.

Information on the Access Adobe project can be found at http://access.adobe.com/ You can access the Adobe Acrobat Access plug-in at http://www.adobe.com/support/downloads/5efe.htm

This page contains a summary of the accessibility issues, many of which are covered by the EASI-WEB Online Workshop on Accessible Web Design offered by Dr. Norm Coombs and Richard Banks through the Rochester Institute of Technology. For more information, you can visit their Web site at http://people.rit.edu/easi/

You’re invited to visit the Colleague to Colleague web site at http://www.ks-alliance.org.