Полезная информация


Special Edition Using HTML 4

Previous chapterNext chapterContents


- 15 -
Making Your Web Sites Accessible to Impaired and International Users

by Mike Morgan

Understanding the Needs of the Visually Impaired

A variety of laws, as well as common courtesy, require architects to make provisions for people with handicaps when they design buildings. Most of us work in buildings with ramps for wheelchairs and Braille on the elevator buttons. When we design Web pages, we need to think about similar needs. A red text against a deep green background may become invisible to someone with red-green color-blindness (the most common form of color-blindness). The tiny fonts commonly used with "Best experienced with" and "Best viewed with" browser buttons are useless to people with limited vision. People with text-only browsers, including speech-based browsers popular with those who have lost their sight, cannot benefit from highly graphical designs.

This section provides guidelines for Web designers who want to ensure that their site is accessible to all users.


NOTE: Some users have other disabilities that interfere with their use of the Web. A user with a neuromuscular disorder may find the mouse difficult to use--he or she may prefer to tab from link to link. A user with certain neurological disorders may be adversely affected by blinking text or by certain animated GIFs.

While the information in this section is primarily aimed at making Web pages accessible to those with visual impairments, application of these guidelines will help people with other needs as well.


While many different disabilities can interfere with a person's use of the Web, the principal limitations are those associated with vision. For our purposes as Web site designers, we need to make our sites accessible to people who may have any of three types of vision impairments:

In addition to the visually impaired, accessibility guidelines contain recommendations for improving the Web experience for the deaf and the hard of hearing. Persons who have some residual hearing are often able to use Web audio by turning up the volume or by using headphones to block background noise. Persons who are deaf need to have information presented in visual form. For example, an audio clip may be accompanied by a transcript or captions.

By following the recommendations applicable to those with visual or auditory disabilities, persons with cognitive or language disabilities are often able to use the Web. A clean, straightforward design with numbered lists and plenty of visual cues will help these individuals find the information on your site.

Some persons with physical disabilities find it difficult to use the mouse. At the operating system level, both Apple and Microsoft include utilities to aid in operating the mouse and keyboard. Check your site with popular browsers to make sure these utilities work correctly. (For example, some Java Virtual Machines override the system's built-in accessibility utilities, such as StickyKeys, MouseKeys, and ToggleKeys.)


ON THE WEB: http://www.boston.com/wgbh/pages/ncam/symbolwinner.html  If you follow the guidelines from this section, you may want to mark your site with the keyhole symbol (shown in Figure 15.1). This symbol was chosen by the National Center for Accessible Media (NCAM) to denote Web sites that contain accessibility features to accommodate the needs of disabled users.

FIG. 15.1
If you follow the guidelines for online accessibility, add this symbol to your Web site.

Access for Those Who Are Color-Blind

Phyllis Rae of the Anitec Imaging Corporation (http://www.anitec.com/) reports that nearly nine percent of the population suffers from some form of color vision deficiency, also known as color-blindness. The perception of color depends upon the health of the cones on the retina. Each cone has one of three types of photopigments, commonly called red, green, and blue. Disease, age, fatigue, and general health can interfere with these cones, distorting the perception of color.

If you don't take care to make sure your site is accessible to people with limited color vision, you risk turning away nearly one out of ten people.


ON THE WEB: http://www.anitec.com/faithful/intro_to_color/7_Physio/index.html   This page on the Anitec site describes the physiological causes and effects of color-blindness.

Jane Berliss, Lewis Kraus, and Susan Stoddard, in their Web paper, "Design of Accessible Web Pages," provide several guidelines on the use of color and pattern.


ON THE WEB: http://www.infouse.com/disabilitydata/guidelines.text.html  If you're serious about designing for accessibility, read "Design of Accessible Web Pages" online.

Here are a few of Berliss, Kraus, and Stoddard's recommendations:


TIP: The latest browsers support Cascading Style Sheets (CSS) so that you can separate content from appearance. Use a style sheet to apply your design decisions. Then, if you find you need to change your design to better accommodate the needs of your audience, you only need to make the change in one place.

For more information about Cascading Style Sheets, be sure to read Chapter 17, "Applying Cascading Style Sheets."



NOTE: According to the World Wide Web Consortium (W3C), browsers may eventually allow the end user to turn off your style sheet or apply one designed by the end user. That way, an end user could develop a style sheet that meets his or her special needs and apply that style sheet to improve the usability of your pages. While the current generation of browsers have been slow to adopt this recommendation, it should be available in the near future. To learn more about the W3C's recommended user interface, see www.w3.org/TR/WD-style#ui.

FIG. 15.2
When seen in monochrome, the text of this page is difficult to distinguish from the background.

FIG. 15.3
This page uses an attractive background graphic, but the text is positioned over the solid part of the graphic.


TIP: Not only are designs with clean backgrounds more accessible to people with limited vision, they generally load faster. The background graphic shown in Figure 15.3 was found on the site of the Bandwidth Conservation Society (www.infohiway.com/faster/). Figure 15.4 shows their page on background design--not only is it highly accessible, but it is a model of a fast-loading page.

Access for Those with Limited Vision

FIG. 15.4
The Bandwidth Conservation Society uses a small background graphic to produce a stunning (and highly accessible) Web page.

A search of a popular online database reveals over 3,000 articles on "disability," but only four matching "disability AND Internet." A search of the Web (through search.com) finds nearly 162,000 pages that address "disability," and 449 that match "disability AND Internet." Of those, 29 also mention accessibility. About a third of those sites appear to be relevant.

All of this information suggests that designing Web pages for accessibility is an emerging technology. Plenty of information is available to help you make your pages more accessible. If you're looking for a way to distinguish your site, consider giving it a clean, accessible design. You don't have to review all of the sites and papers that describe accessibility. Staff at the Trace R&D center at the University of Wisconsin (http://www.trace.wisc.edu/text/guidelns/htmlgide/htmlgide.htm) have reviewed the guidelines from many sources and listed the "Unified Web Site Accessibility Guidelines." This section, on access for persons with limited vision, and the next section, addressing those who use screen readers, is based on these unified guidelines.


ON THE WEB: http://www.microsoft.com/enable/dev/guidelines.htm  If you're developing a product that will participate in the Windows 95 or Windows NT logo programs, pay attention to the accessibility guidelines here on the Microsoft site. You must comply with them in order to win your logo.

Designing Text for Accessibility  Before the introduction of the <FONT> tag and Cascading Style Sheets, some Web designers used bitmapped text to get the precise effect they wanted. This approach was of dubious benefit to sighted users, and it can cause serious problems for persons with limited vision. If the visitor wants to increase the size of the text, the graphic doesn't scale. If the visitor is using a screen reader, he or she is told only that there's a graphic present. Today, the best way to manage the appearance of your pages is through style sheets. Let the end user override the style sheet if he or she needs to increase the text size. If you must include a graphic, be sure to provide usable ALT text, or a text-only version of the page.

Take a look at Figure 15.5. The code for that graphical link is:

<A HREF="http://housecall.antivirus.com/"><IMG SRC="Ambu.gif" 
ALT="Run anti-virus scan" HEIGHT=104 WIDTH=104></A>

FIG. 15.5
Use ALT text to provide cues to text-only readers.

Browsers like Netscape Communicator 4.0 display the ALT text when the user moves the cursor over the image. If the user has turned off image autoloading, most browsers will display the ALT text in lieu of the graphic. If the user's graphic is text-only, such as Lynx, the user sees only the ALT text.


ON THE WEB: http://ugweb.cs.ualberta.ca/~gerald/lynx-me.cgi  If you don't have access to Lynx, use this CGI script to get a feel for what text-only visitors see.


TIP: Be sure that visitors to your site know how to change the font size on your page. You may want to use some JavaScript to detect the type and version of browser and then provide a link to a page of instructions that tell the user how to control the appearance of the page. Listing 15.1 shows how to detect a particular browser and version.

Listing 15.1  appVer.js--Use JavaScript to detect the type of browser the user is running.

var theNavigatorResult = navigator.appVersion.indexOf("\(Win");
var theExplorerResult = navigator.appVersion.indexOf("Windows");
// Find out if this machine is running Netscape and Windows
if (theNavigatorResult != -1)
{
  document.write("<P>To change the font size in Netscape Navigator, 
choose Edit, Preferences. Then choose Appearance, Fonts. Set the 
font sizes as desired, and check \"Use my default fonts, 
overriding document-specified fonts.\"</P>");
}
else
if (theExplorerResult != -1)
{
  if (navigator.appVersion.indexOf("MSIE 4") == -1)
  {
    document.write("<P>To change the font size in MSIE, choose 
View, Fonts, and choose a font size.</P>");
  }
  ...
}


TIP: Be sure to use proportional markup such as <H1> and <H2> rather than fixed font sizes so that user can adjust the size of the font. Similarly, use logical markup such as <EM> and <STRONG> rather than physical styles such as <I> and <B>. Learn more about styles in Chapter 6, "Applying Character Formatting."

If a user's browser allows him to set his own style sheet, you can encourage him to use settings that meet his particular needs. For example, the user could apply a rule such as the following:

BODY {font-size: xx-large}

Just be sure you don't lock the size attribute in your style sheet by writing this:

BODY {font-size: medium | important}

Preformatted Documents  Many Web sites include documents with complete formatting information, such as those written in Adobe's Portable Document Format (PDF). Adobe offers an online server (called Access) and a Windows plug-in (at http://www.adobe.com/prodindex/acrobat/accessplugin.html) that allows users to convert PDF files to HTML offline.


ON THE WEB:
http://access.adobe.com/  Use the forms available from this site to convert PDF files to HTML. The resulting HTML can be read by increasing the font size or using a screen reader.

For example, http://www.adobe.com/prodindex/PDFS/sourcebooksp97.pdf contains a 40-page color catalog of Adobe's products. (The file is approximately 5.8M.) Figure 15. 6 shows the result of converting the first two pages with Adobe's access server.

FIG. 15.6
Use the advanced form to specify which pages should be converted.


TIP: If you include PDFs in your site, provide a link to one or both forms at access.adobe.com. Adobe encourages users to convert PDF documents online, through their server. Users should only need to use the Access plug-in if they're working with PDFs that are not available from the Internet.

Graphics  Site visitors with limited vision may find it difficult to use imagemaps. If you're providing a text-only version of your page, just replace the imagemap with conventional anchors. If you are serving one version of the page for all users, be sure to include ALT text. If the user is using a browser that supports client-side imagemaps, he or she will be able to use the ALT text as a navigational aid. Listing 15.2 shows one way to code a client-side imagemap.

Listing 15.2  imagemap.html--Include ALT Text in Your Client-Side Imagemaps

<IMG SRC="virginia.gif" ALT="Image Map of the State of Virginia" 
USEMAP="#map1" BORDER=0>
<MAP NAME="map1">
<AREA COORDS="0,0,30,30" HREF="northva.html" ALT="Northern Virginia">
<AREA COORDS="34,34,100,100" HREF="hamproad.html" ALT="Hampton Roads">
</MAP>


CAUTION: If you set the colors in a style sheet, your visitors may be stuck with them. In some browsers, the browser colors don't override the colors specified in the style sheet.

For example, Navigator 4.01 allows the user to choose Edit, Preferences, Appearance, Colors, and then check Always Use My Colors, Overriding Document. Unfortunately, this option does not override colors specified by a style sheet.

In IE 4.0, users can override style sheet colors by choosing View, Internet Options. Then, in the General tab, choose Accessibility and check Ignore Colors Specified on Web Pages. The end user can also specify a personal style sheet from this dialog box.


Multimedia  If you include audio or video in your site, you need to ensure that the information is accessible in alternate forms. You may want to provide a transcript of the audio clip or stream for the benefit of people who are hard of hearing or deaf. People who are using a search engine to locate a particular part of an audio or multimedia clip will also benefit from a transcript.


ON THE WEB: http://library.whitehouse.gov/?request=audio  When the President prepares his weekly radio address, he releases a written transcript as well as the audio broadcast. The White House staff indexes the audio clip to the Web site--you can search for a particular word or phrase and then hear the President's comments on that topic. Figure 15.7 shows this design in action.

You can use Netscape's Media Server to build a site that presents synchronized audio and Web pages. This design allows you to present textual information synchronized to an audio stream. You can also add a "closed-caption" track to a QuickTime video.


TIP: To synchronize a multimedia presentation with a Netscape Media Server audio narration, you add a [Timeline] section to the LiveAudio Metafile (also known as a .LAM file).

User Interaction  Web developers tend to use Java applets to build complex user interfaces that cannot be easily implemented in HTML. Users with limited vision may find the complexity of these applets difficult to navigate.

FIG. 15.7
Search for a word such as "Bosnia," and follow the links to hear the President address the subject.

The Trace R&D Center at the University of Wisconsin (the same folks who prepared the unified guidelines for accessibility) prepared a set of recommendations for Sun Microsystems. While most of the recommendations apply to the language developers, Section II D of their report applies to applet programmers:

While these recommendations can be carried out by using version 1.1 or higher of the Java Development Kit, even a cursory review of the available applets shows that most programmers have not followed these recommendations. If you want to ensure accessibility, you must either avoid most Java applets or have them written to your specifications.

Java programmers can take advantage of accessibility features built into the latest version of the Java Foundation Classes. For more information, visit http://java.sun.com/products/jfc/index.html#access.


ON THE WEB: http://trace.wisc.edu/java/report.htm  Read Trace's report to Sun about ways to add accessibility to Java applets.


TIP: Not all browsers support Java, and not all users enable Java in their browsers. If you add an applet to your site, be sure to include code to accommodate non-Java users:

<APPLET CODE="geosearch.class" WIDTH=100 WIDTH=50
ALT="This applet allows the user to perform database searches,
with the results displayed on maps.">
<IMG SRC="geosearch.gif">

<P>If you were using Java, an applet would appear here that allows you
to search the database and view the results on a map.</P>
</APPLET>



NOTE: The <APPLET> tag has been deprecated in HTML 4.0, meaning that it is still supported, but new pages should use the <OBJECT> tag. The <OBJECT> tag allows you to install applets with powerful new features. See http://developer.netscape.com/library/wpapers/beanconnect/index.html to learn how to use the <OBJECT> tag to install BeanConnect components--Java applets that communicate with each other and with HTML forms and JavaScript.

While Trace did not specifically address ActiveX controls, the recommendations it makes to applet programmers are equally relevant to ActiveX developers. Like most applet programmers, most ActiveX developers have not addressed accessibility. If you want to use ActiveX controls on your site, consider having them written to your specifications.


ON THE WEB: http://www.microsoft.com/enable/products/java.htm  Microsoft has announced that its implementation of the Java Virtual Machine explicitly supports features to aid accessibility.

Testing  Some of the best tools for testing the accessibility of your site are the ones you're already using: validators, WebLint, and Doctor HTML. Learn about validators and related tools in Chapter 39, "Verifying and Testing HTML Documents."


ON THE WEB: http://www.cast.org/bobby/  To ensure that your HTML is accessible, add Bobby to your list of HTML checkers. Bobby includes checks for a number of accessibility rules, including the ones given in this section. It will show you where the problems are and give recommendations on how to fix them.

Access for Those Who Use Screen Readers

People with some residual vision may be able to get information from a Web page by increasing the contrast and enlarging the text and images. For persons who are blind, however, the tool of choice is the screen reader. A screen reader is a software application, often operated in conjunction with a hardware speech synthesizer, that translates the text on the screen to spoken words. This task is a difficult one, particularly in light of complex Web pages with multiple interacting frames, bitmapped text, and now, push technology.

A typical screen reader begins in the upper-left corner of each window--HTML frames are often treated as separate windows--and works from left to right and then top to bottom (just the way we read). When it finds text--not a graphic shaped like text--it passes that text to the speech synthesizer.

Like most PC accessories, speech synthesizers can be internal or external and may be implemented in hardware or software. The most popular speech synthesizers are external hardware devices connected to the computer through the serial port. The speech synthesizer has a table that helps it determine how to pronounce English words. It also has a table of "exception words." Using these rules and tables, the speech synthesizer produces sound that, hopefully, resembles the way a human would pronounce the word. Speech synthesis results are mixed. Like most products, you get what you pay for. Many blind people are limited by inexpensive and unsophisticated speech synthesizers and have had to learn to be creative when interpreting the sounds their synthesizers make.


ON THE WEB: http://www.prairienet.org/benchmark/  Jim Fay has made it his business to provide descriptions and recommendations on all sorts of technology that assists people with disabilities. Visit his site to read about screen readers.


ON THE WEB: http://www.austin.ibm.com/sns/index.html  IBM offers a comprehensive set of accessibility tools called the Special Needs System. Its screen reader is described at www.austin.ibm.com/sns/snssrd.html.


NOTE: If a user needs access to a page in a language other than English, they need to have a screen reader and a synthesizer that support that language. Many screen readers and synthesizers support common European languages such as French, Spanish, and German, but the user must be sure to switch both the screen reader and the synthesizer when he or she opens the non-English page.


TIP: Screen readers are primarily designed for the blind community. Some sighted dyslexic users--particularly stroke victims--have reported that screen readers aid them in understanding Web pages. If you're a Web developer, be aware that some users may use their screen reader on single words. If you're dyslexic, check with your health care professional to see if such a device might be useful in your case.

Screen readers will work with any Windows application--they are as useful with Microsoft Word as they are with Netscape Navigator. There's another class of software--speech browsers--that support the direct transformation of HTML to speech. For example, Productivity Works, Inc. (www.prodworks.com) makes a browser--pwWebSpeak--that drives a speech synthesizer directly from HTML.

NetPhonic (www.netphonic.com) has developed a system--Web-On-Call--that provides access to Web pages via telephone. As a Web publisher, you need to install its server as well as hardware to connect your system to the telephone lines. It supports up to eight lines with off-the-shelf configurations and can scale beyond that number with custom configurations.


TIP: NetPhonic is not aiming its product at the market of visually disabled people. It is selling its system as a telephone-based interactive voice response system. If you design your Web site for screen readers and add a Web-On-Call server, you could have your Web site double as a set of telephone menus. Visit http://www.netphonic.com/demo/contact.htm to get access to a demonstration.

In addition, most conventional browsers offer accessibility enhancements, either through operating system utilities or through built-in capabilities.


ON THE WEB: http://www.microsoft.com/ie/most/howto/?/ie/most/howto/access.htm  Learn how to operate Microsoft Internet Explorer without a mouse. For best results, open this page while you're in MSIE 3.0 or above--the server will install an ActiveX accessibility utility.

Designing Text for Accessibility  Many screen readers are like the text-based Lynx Web browser--the user uses the Tab key to advance from link to link. Unlike Lynx, the user hears only the text of the link itself. Thus, a link like

<A HREF="http://www.trace.wisc.edu/">Click here</A>
to visit the Trace site.

will give the user only the words "Click here." A better design might be

<A HREF="http://www.trace.wisc.edu/">Visit the Trace site</A>.

With this approach, the user is encouraged to "Visit the Trace site," a much more interesting prompt.


TIP: If you have a series of links, place them in a list or separate them by <BR> tags. Some screen readers become confused if there's more than one link on a line and run them together.

Likewise, be careful about text in tables. Screen readers read one line at a time, while the human eye will often read down the column. Either design your tables so that they can be read a line at a time, or rethink your design to avoid the table. (For example, you might offer a text-only version of the page that provides the information in paragraphs instead of a table.


Screen readers usually ignore (or sometimes mispronounce) punctuation marks. Don't use nonstandard punctuation such as emoticons (for example, :-)) in any material that may pass through a screen reader.

Screen readers have a particularly difficult time moving or changing text. Text surrounded by the <BLINK> or <MARQUEE> tags, or scrolling text displayed by Java applets or JavaScript, will cause the screen reader to misspeak and may even crash the program. For best accessibility, provide a text-only equivalent of any pages that use these special features.


ON THE WEB: http://www.trace.wisc.edu/world/java/java.htm  For tips on the use of both Java and JavaScript on your accessible Web site, visit this page on the Trace R&D Center's Web site.

Page Layout  Many modern Web pages display multiple columns, sometimes implemented through frames. Figure 15.8, for example, shows the CNET channel in Netcaster. The screen is loaded with content, but a screen reader may present this content in a confusing way.

FIG. 15.8
Multiple columns of information can be confusing when read by a screen reader.

Netscaster and the various channels are described in Chapter 32, "Building Netscape Netcaster Channels."

If you need to present information in multiple columns, consider offering a text-only page for the benefit of low-bandwidth users and visitors with screen readers. Another nice design is to use icons (with ALT text) in each cell of the table. Figure 15.9 shows the U.S. Postal Service's WINGS site, which uses this design.


TIP: If your site is generated directly from a spreadsheet or a database, you may not want to invest the time to build a text-only version of each page. Consider providing a phone number or e-mail address; encourage someone who needs help interpreting the data to contact you directly.

Most Web designers feel comfortable dropping an unordered list (<UL>) onto any page. Users with a screen reader may find it difficult to tell where the list begins and ends. The screen reader may run adjacent list items together or separate into two or more items those items that need multiple lines. Consider switching to ordered lists (<OL>) and cueing the reader by announcing the number of items on the list. For example, the list in Listing 15.3 is considered a more accessible design than the one in Listing 15.4.

Listing 15.3  ordered.html--Ordered Lists Put Numbers on Each List Element

<P>Our solar system has nine major planets.</P>
<OL>
<LI>Mercury</LI>
<LI>Venus</LI>
<LI>Earth</LI>
<LI>Mars</LI>
<LI>Jupiter</LI>
<LI>Saturn</LI>
<LI>Uranus</LI>
<LI>Neptune</LI>
<LI>Pluto</LI>
</OL>

FIG. 15.9
The U.S. Postal Service operates the Web Interactive Network of Government Services (WINGS), considered by many to be a model of accessibility.

Listing 15.4  unordered.html--An Unordered List Shows only Bullets

<P>Let's review the planets in our solar system.<P>
<UL>
<LI>Mercury</LI>
<LI>Venus</LI>
<LI>Earth</LI>
<LI>Mars</LI>
<LI>Jupiter</LI>
<LI>Saturn</LI>
<LI>Uranus</LI>
<LI>Neptune</LI>
<LI>Pluto</LI>
</UL>


NOTE:umbering lists can also help people with certain cognitive disabilities by providing them with cues about where they are in the list.


ON THE WEB: http://trace.wisc.edu/wings/  Visit this page for good examples of HTML lists. One such list is shown in Figure 15.10. Continue on into the links on this page for even more information about how to design for high accessibility.

FIG. 15.10
This page from the Trace R&D Center at the University of Wisconsin shows how to ensure that lists work well with screen readers.
Learn more about lists in Chapter 9, "Adding Lists to a Web Page."


TIP: If your style guide requires bullet lists when no particular order is required, but you're content to allow visitors to see numbered lists when they need them, encourage those visitors to apply their own Cascading Style Sheet (CSS). Here's a rule that will switch all of their lists to numbered lists:
UL LI {list-style-type: decimal}

In general, frames wreak havoc with screen readers. If you choose to use frames, use the <NOFRAMES> tag to display a text-only version of each page. Users with small monitors will appreciate the ability to reduce the screen clutter as well. Learn more about frames in Chapter 12, "Framing Your Web Site."

Graphics  It's not just the blind who are unable to see graphics. Users with slow modem connections often choose to disable image autoloading in order to improve performance. Many users, particularly those on college campuses, access the Internet though a text-only browser: Lynx. In order to satisfy the needs of these users, you must ensure that information is presented in a textual form as well as graphically. For example, if you provide an imagemap, be sure to include conventional links. If the image has meaning for nongraphical users, include ALT text so they know what the graphic was.


TIP: Site visitors with certain cognitive disabilities may find it easier to work with graphics than with text. Similarly, people with neuromuscular disorders often find imagemaps with large clickable targets to be easier to use than small text links. For maximum accessibility, provide both text and graphics and let the user choose how they want to interact with your site.

When you design your ALT text, be sure to keep it simple. Some screen readers have problems if the text wraps inside the rectangle reserved for the graphic. Be sure to include punctuation at the end of the ALT text so that the screen reader inserts a pause. That way the ALT text doesn't run together with the other text on that page.


TIP: If you use horizontal lines to separate sections of your page, use an <IMG> tag rather than an <HR> tag. That way you can attach text like ALT="Horizontal line." so that the text-only user is aware that you are starting a new section. If the nature of the new section is not clear from the text, you might even have the ALT text of the horizontal line introduce the section. For example, you could write

<IMG SRC="graphics/blueline.gif"
ALT="--------------Section 3. ComputerViruses------------------"
HEIGHT="8" WIDTH="480">

The dashes in the ALT text help the sighted text-only user see that a new section is coming up.


Sometimes a graphic is purely decorative, and no ALT text is appropriate. If you leave the ALT text off, many screen readers and text-only browsers will tell the user that a graphic exists, leaving the user to wonder what they are missing. Just set ALT="" to tell the text-only visitor that they can safely ignore the graphic.


TIP: If you have some graphics that need more explanation than you can put in an <ALT> tag, consider placing a small transparent GIF after the graphic. (GIFs are image files based on the Graphical Interface Format. Transparent GIFs have one color set to be "transparent," so that the background color appears through the image.) Make the image a link to explanatory material, perhaps in a footnote at the bottom of the page. Because the GIF is transparent, it will be invisible to sighted readers who have graphics enabled. Text-only readers will see the GIF's ALT text. If they follow the link they'll get a textual description of the graphic that they couldn't see. Figure 15.11 shows an example of this technique, as viewed from Lynx.

FIG. 15.11
Use an invisible GIF to cue text-only readers that a description is available.

If you find that your pages have so many graphics that the ALT text and links to descriptions become tedious, consider developing a text-only version of your site. You can also build a hybrid site--ask the user if he or she prefers a graphics-rich version of the site or a faster, mostly text version. Use JavaScript to store his or her answer in a cookie, as shown in Listing 15.5. Then build your pages with a server-side script such as Netscape LiveWire, Microsoft's Active Server Pages, or CGI. Each page should examine the contents of the user's cookie and return an appropriate version of the page. For many pages, they will be only a few graphics. You could serve those pages to all users and build only two versions of the page when necessary.

Listing 15.5  cookies.js--Use Cookies to Save a Form's State

<SCRIPT LANGUAGE="JavaScript">
// These functions are designed to integrate with an HTML form
// named "FEEDBACK," which has text fields Mail and Memo and
// checkboxes Speed, Content, and Graphic.
// Modify WriteCookies() and GetCookies() to work with your 
// own forms.
function GetValue( Offset )
{
// Extract the value from the cookie at the given offset
  var End = document.cookie.indexOf(";", Offset);
  if ( End == -1 )
    End = document.cookie.length;
// Return the portion of the cookie beginning with the offset
// and ending with `;'.
  return unescape( document.cookie.substring( Offset, End) );
}
function GetCookie( Name)
{
// Return the value of a cookie by name.
  var Len = Name.length;
// Look at each substring that's the same length as the cookie name
// for a match. If found, look up the value and return it.
  var i = 0;
  while (i < document.cookie.length )
  {
    var j = i + Len + 1;
    if ( document.cookie.substring( i, j ) == (Name + "=") )
      return GetValue( j );
    i = document.cookie.indexOf( " ", i ) + 1;
    if ( i == 0 )
      break;
  }
  return null;
}
function SetCookie( Name, Value, Expire )
{
// Make or change a cookie given its name and value. The name and value
// are required, but the expiration date isn't. Note that if you don't
// specify an expiration date, the cookie only exists for the current session.
  document.cookie = Name + "=" + escape( Value ) + ";expires=" + Expire;
}
function WriteCookies()
{
// Write all the cookies for the FEEDBACK form
  var Expire = "Friday,25-Feb-2000 12:00:00 GMT";
  with ( document.FEEDBACK )
  {
    SetCookie( "Mail", FEEDBACK_MAIL.value, Expire );
    SetCookie( "How", FEEDBACK_HOW.selectedIndex, Expire );
    SetCookie( "Memo", FEEDBACK_MEMO.value, Expire );
    SetCookie( "Speed", FEEDBACK_SPEED[0].checked ? "1" : "0", Expire );
    SetCookie( "Content", FEEDBACK_CONTENT[0].checked ? "1" : "0", Expire );
    SetCookie( "Graphic", FEEDBACK_GRAPHIC[0].checked ? "1" : "0", Expire );
  }
}
function GetCookies()
{
// Load the form with the values in the cookie
  with ( document.FEEDBACK )
  {
     FEEDBACK_MAIL.value = GetCookie( "Mail" );
     FEEDBACK_HOW.selectedIndex = GetCookie( "How" );
     FEEDBACK_MEMO.value = GetCookie( "Memo" );
     FEEDBACK_SPEED[0].checked = GetCookie( "Speed" ) == "1";
     FEEDBACK_SPEED[1].checked = GetCookie( "Speed" ) == "0";
     FEEDBACK_CONTENT[0].checked = GetCookie( "Content" ) == "1";
     FEEDBACK_CONTENT[1].checked = GetCookie( "Content" ) == "0";
     FEEDBACK_GRAPHIC[0].checked = GetCookie( "Graphic" ) == "1";
     FEEDBACK_GRAPHIC[1].checked = GetCookie( "Graphic" ) == "0";
  }
}
</SCRIPT>


NOTE: The Portable Network Graphic (PNG) allows you to embed a text description in the graphic itself. PNG is gradually taking its place along side GIF and JPEG graphics. Look for browsers to give users access to PNG's built-in text.

Multimedia  Many sites include complex media types such as large images or video clips that are displayed using browser plug-ins or ActiveX controls. Users with a slow network connection may choose to skip these embedded files. Users without the proper plug-ins have to take extra steps to access the information. Visually impaired users may not be able to see the data at all. For more information about embedded objects see Chapter 14, "Inserting Objects into a Web Page." For all these reasons, be sure to include a link to a description of each embedded file. You should describe the contents of the file. You may also want to tell the user how to configure his or her browser so the sighted user can view the file. Be sure to give the user some idea of how large the file is so that he or she can make a decision whether to invest the download time.

Michael Herrick of Matterform Media has designed a collection of tiny icons called QBullets. In general, you can place a QBullet after a link to tell the site visitor what that link does (for example, opens a form, leads to a list of links, or initiates a file download). Herrick includes a series of thermometer icons in his collection so that you can tell the visitor the approximate size of the downloadable file.


ON THE WEB: http://www.matterform.com/qbullets/  Download the latest set of QBullets from Matterform's site.

If a graphic is central to the point of your Web page, consider leaving a link to it on the text-only version of the page. That way, the visually impaired user can open the link and show it to a sighted colleague.

User Interaction  Most screen readers work well with the major browsers to read HTML forms. If you want to be sure that everyone has the opportunity to fill out your form, allow the user to request a form by e-mail so they can print it out, or supply a phone number so they can supply the information over the phone. Information about how to build HTML forms is found in Chapter 13, "Collecting Input with Forms."


NOTE: Some screen reader users report that occasionally they will not hear the screen reader report an edit box if that box is empty. The solution is to add a space to the box:
<INPUT TYPE=Text NAME="AnEditBox" VALUE=" " SIZE=20>


ON THE WEB: http://web.mit.edu/wwwdev/cgiemail/  This site provides a CGI script for e-mailing forms.

Testing  As a simple test of any Web page, place a piece of paper against the screen and slowly move it down. As you reveal text, read it--you'll get a pretty good idea of how most screen readers will render your document. Most screen readers will treat each frame like a separate document, so process one frame at a time. If you don't like the effect, include a <NOFRAMES> version.


ON THE WEB: http://www.wwwebit.com/magical-mist/ribbon.htm  Once your page is ready for final testing, submit it to mist@cdepot.net. They'll give you recommendations on how to ensure that your page is compatible with most screen readers. Once you have their seal of approval, you can display the "Speech Friendly Site" ribbon.


ON THE WEB: http://www.w3.org/TR/WD-acss  If you're already using Cascading Style Sheets (CSS) get ready for Audio CSS, or ACSS (pronounced "access"). If adopted, this standard could allow you to add audio markup to your documents in much the same way you now use CSS for visual markup. While you're on the W3C site, read www.w3.org/TR/WD-print to see how to use style sheets to tune your pages for good appearance in print.

Understanding the Needs of the International Audience

Twice every year the Graphics, Visualization & Usability Center (GVU) at Georgia Tech (www.gvu.gatech.edu/user_surveys/) conducts a survey of Web users. For the past year the percentage of users who live in the U.S. has been dropping--in the 7th Survey, conducted in April 1997, that percentage had fallen to just over 80 percent (http://www.gvu.gatech.edu/user_surveys/survey-1997-04/graphs/general/Major_Geographical_Location.html). That same survey found that almost 92 percent of Web users used English as their primary language, but in Europe, both German and French had increased dramatically.


NOTE: The Georgia Tech surveys are conducted twice a year, in April-May and in October-November. To participate, visit http://www.gvu.gatech.edu/user_surveys/ during the survey months and follow the link to the current survey forms.

The import is clear--there really is a World Wide Web. If you want to develop a site that has truly global impact, you need to think about making your site accessible to people who do not speak English, or at least to people who are more comfortable in a different language.

In order to support a language, you must combine three components:

To develop the content, you'll need a translator. Be aware that some computer concepts, such as the wording on buttons or other controls, need to change to match the target culture (a concept variously known as internationalization and localization). Be sure to get a translator who has experience with Web sites.


ON THE WEB: http://www.yahoo.com/Social_Science/Linguistics_and_Human_Languages/Translators_and_Interpreters/  Visit this Yahoo! category to learn more about translators. From here you can find commercial translators as well as a few free services. You'll also want to visit www.yahoo.com/Business_and_Economy/Companies/Computers/Software/Localization/ for ideas on localization. You'll find a FAQ on internationalization at http://www.vlsivie.tuwien.ac.at/mike/i18n.html.

The remainder of this section addresses encoding issues and methods for seamlessly serving the right translation when the user requests the document.


ON THE WEB: http://www.javasoft.com/docs/books/tutorial/intl/concepts/features.html  Java 1.1 supports several new features, including a Locale class, ResourceBundles, and Format classes, which aid in developing localized versions of a Java applet or application.

Understanding Encodings

Before a Web client can display a Web page, the client must know how the page designer intended each character to be displayed. The first question for the client is, "How many bits correspond to each character?" Since the number of symbols in a character set is limited to two to the number of bits, the size of the character "package" limits the number of characters. For most European languages, 256 characters is plenty. For some Asian languages, even 65,535 may not be enough. (In China, people are inventing new characters every day, principally for use in personal names.)

This section describes the three major types of encoding: 7-bit ASCII, 8-bit ISO-8859, and 16-bit Unicode.

Simple ASCII  The earliest computers shared much in common with the teletype industry. Characters were encoded in 7 bits. Since 27 is 128, these first codes could represent 128 characters--enough for the upper- and lowercase letters, the numbers, and a few dozen punctuation and control characters. Someone has to decide which of the numbers from 0 to 127 should stand for a k, and which for an A, and so on. The two leading contenders for a standardized encoding were IBM's Extended Binary Coded Decimal Interchange Code, or EBCDIC, and the American Standard Code for Information Interchange (ASCII). While IBM still uses EBCDIC in some of its larger computers, ASCII has come to dominate the industry. There is an ASCII standard that specifies which characters correspond to which number. (For example, K is 107 and A is 65.)

As time wore on, it became clear that computer data was easier to manipulate when it was stored in containers with a width equal to a power of two. It has become common to store characters in bytes--containers that are 8 bits wide. Since 28 is 256, there's room for 128 more characters beyond the ASCII standard. In the desktop computer industry, each manufacturer chose symbols as they saw fit. (For example, Apple filled the upper 128 characters with some mathematical symbols and some international currency symbols such as the pound sterling and the yen. IBM's PC has smiley faces and the symbols for the four suits of cards.)

ISO-8859 Encodings  After a few years of sibling rivalry among the desktop computer manufacturers, the international standards community defined a series of encodings that take advantage of the upper 128 characters. If your Web pages were prepared by an editor such as Netscape Composer, you may find a line at the top of the file that specifies the encoding:

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset="iso-8859-1">

ISO-8859-1 is the Latin character set that native English speakers recognize. Many European languages use character sets that are similar to English but have a few special characters of their own. For example, ISO-8859-2 supports central European languages. Other languages, such as Russian, have an alphabet that is based more on Greek than on Latin. ISO-8859-5 supports the Cyrillic encoding. Similarly, ISO-8859-7 supports Greek and ISO-8859-9 supports Turkish.


ON THE WEB: http://www.utoronto.ca/webdocs/HTMLdocs/NewHTML/iso_table.html  You can get a complete listing of the ISO-8859-1 characters online. For a list and character set of all of the ISO-8859 standards, see www.wbs.cs.tu-berlin.de/~czyborra/charsets/. Remember, the first 128 characters of each ISO-8859 standard are simply the ASCII characters.

You can change the encoding your browser uses from the menu. In Microsoft Internet Explorer 4.0, for example, choose View, Internet Options. Click the Fonts button on the General tab, and set the desired Character Set. You'll see the change only if you're looking at a page that uses the "upper 128," since most English pages only use standard ASCII.

For example, visit www-koi.kulichki.com/ostrova/bera/Folklor/index.html. This page is in Russian and is encoded in Cyrillic. Set your encoding to ISO-8859-5 (Cyrillic) to see the page shown in Figure 15.12.

FIG. 15.12
Be sure to set your encoding to match the language of the site you're visiting.

Beyond 8 Bits: Unicode  Many languages, such as the languages of Eastern Asia, require far more than 256 symbols. The latest entry to the encoding field is Unicode, which supports 65,536 discrete symbols by making the package for a character 16 bits wide.


NOTE: The World Wide Web Consortium (W3C) has committed to the internationalization of the Web. To that end, they have specified that Unicode, rather than ASCII, is the base character set of HTML, beginning with HTML 4.0. Look for more sites to start using Unicode (ISO 10646-1).


ON THE WEB: http://www.unicode.org/  Unicode has a home page! Learn everything you want to know about this encoding standard.

Offering Alternative Languages

If you're serious about internationalization, sooner or later you have to deliver the contents of your Web site in the target language(s). If you have the latest server, and if your visitors are using a late-model browser, you can automate the process. Otherwise, provide links to each target language and let the user choose.

Using HTTP/1.1 to Offer Language Variants  When a Web browser contacts a Web server to request a resource such as a Web page, the two software applications communicate by using a protocol called HTTP--the HyperText Transfer Protocol. In January, 1997, version 1.1 of that protocol was formally adopted as a "standards-track" specification. That fact means that Request For Comments (RFC) 2068 is now undergoing final review. Unless someone finds a serious flaw at the last minute, HTTP 1.1 will become the standard for Web browsers and servers. The major browser and server vendors are already adding HTTP 1.1 features to their products. What does all of this standards activity have to do with international accessibility? Just this: beginning with HTTP 1.1, an end user can list his or her preferred languages, and the browser and the server can negotiate to find a suitable version of the document. Here's an example of how that negotiation works:

Client to Server:
I'd like a copy of the Product Catalog. I have a PDF reader and an HTML browser. I'd prefer a version in German, but can accept English.
Equivalent HTTP headers:
ACCEPT text/pdf; q=0.9, text/html; q=0.1
ACCEPT-LANGUAGE de; q=0.8, en; q=0.2 
GET prodcat HTTP/1.1
Server to Client:
Here it is.
Equivalent HTTP headers:
HTTP/1.1 200 OK
VARY ACCEPT, ACCEPT-LANGUAGE
Content-type: text/pdf prodcat.en

The client, a Web browser, tells the server that the user prefers to receive the document in Adobe's Portable Document Format (PDF) but will accept HTML. He also prefers a German version but will accept English.

The Web server replies by sending the PDF version of the document. Since it doesn't have a German copy, it sends the English version.


TIP: If you'd like to offer your documents in more than one language, check with your Webmaster to see if your server supports HTTP/1.1. Read your server's documentation or follow your Webmaster's instructions about how to name your documents so that the server can recognize the language of each document.

Setting Up the Browser for Language Variants  The newest browsers now allow you to specify the languages you want them to request. For example, in Netscape Communicator, choose Edit, Preferences and choose Navigator, Languages. Figure 15.13 shows the resulting dialog. Use the Add button and the up and down arrows to list the languages you will accept, in the order you prefer them. For example, the figure shows that the user prefers any type of German but will accept any type of English. (German is available in Austrian and Swiss variations, in addition to German as spoken in Germany; English is available in both British and U.S. varieties.)

FIG. 15.13
Use the Languages preference to specify which languages you will accept.

Older Ways to Offer Translations  If your server, or your user's browsers, aren't ready for HTTP/1.1 yet, but you want to offer your information in more than one language, follow the time-tested method of listing all of the available languages on the first page of your site. (Many developers also include a small flag representing the home nation of each language.) The new visitor reads down the list until she sees an offer she can understand, then follows that link to the first page of the site in her preferred language. Figure 15.14 shows such a site.


NOTE: If you connect to SavvySearch from outside the U.S., you may see the site displayed in your native language. Dreilinger has programmed his CGI script to do a reverse lookup on your IP address to get the country of your domain. Then, he looks at a table to determine what your native language (most likely) is and sets his language parameter to match your language (if he has an appropriate translation on file).
This approach isn't perfect, but it's a nice touch.

FIG. 15.14
Daniel Dreilinger, developer of SavvySearch, has lots of friends fluent in different languages.


Previous chapterNext chapterContents


© Copyright, Macmillan Computer Publishing. All rights reserved.