| Server-side scripts, such as Common Gateway Interface (CGI), are run on the Web server and triggered by a request from the browser. Client-side scripts, such as JavaScript, create programs that may accompany an HTML document or be embedded directly in it. Client-side scripts often run on the user machine when the document loads. A script may also run at other times, such as when a user selects a link. HTML support for scripts is independent of the scripting language, which allows Web authors to extend HTML documents in highly active and interactive ways. For example, scripts may be evaluated as a document loads to dynamically modify the contents of a document. Scripts may accompany a form to process input as it is entered. A scripted program may dynamically fill out parts of a form based on the values of other fields and ensure that fields are mutually consistent. Scripts may be triggered by events that affect the document, such as loading, unloading, element focus, or mouse movement. Scripts may be linked to form controls to produce graphical user interface elements. All of these can create accessibility barriers but it doesn't have to be that way! Let's begin by considering the <script> element and some of the common attributes you might find in the code samples included in this chapter. The type attribute specifies the scripting language of the element's contents as a content type (for example, "text/javascript" ). You should specify the type attribute for each instance of a <script> element within a document. Using the attribute overrides the default scripting language. Authors must supply a value for this attribute since there is no default value. Note that while it is still common to find the language attribute used, it has been deprecated. The language attribute specifies the scripting language for the <script> element. Its value is an identifier for the language, but because the identifiers are not standard, this attribute has been deprecated in favor of type. The defer attribute can be set as a Boolean indicator that the script is not going to generate any document content. For example, if it is set, the defer attribute will defer the document.write command in JavaScript, allowing the user agent to continue parsing and rendering. Now let's look at some of the common uses for scripts and how to make them most accessible. Scripting Rollovers for Accessibility One of the most popular JavaScript functions is to animate a graphic link when the mouse rolls over that area of the screen a mouseover event. This mouseover technique is often used to provide feedback about user actions, for example, by changing the color of a link when the mouse moves across it. It's also used to provide additional information: when the mouse pointer moves across the image, the image seems to be replaced by text, which disappears when the user moves the mouse again. (This text isn't really text, however it's actually an image of text, which means that many people can read it but screen readers can't, and it may be difficult for some people to read, too, since the text is often displayed in a very small font.) Rollovers provide feedback about user actions on the Knowbility Web site shown in Figure 14-1. The Knowbility site uses a vertical navigation scheme with an orange background and graphic tags indicating the interest areas to which the user may link. As the mouse travels across the navigation bar, the background of the potentially activated link changes from orange to yellow. Figure 14-1. Screen shot of the Knowbility home page, which demonstrates the use of mouseovers coded in JavaScript to create animated color changes that aid users when navigating the site. Accessed January 10, 2002, at http://www.knowbility.org. Used with permission.  To ensure maximum accessibility for an event of this type, you must provide two things: keyboard navigation and a text alternative. First, the link itself must be accessible by means other than the mouse in other words, through keyboard navigation. As we've seen throughout this book, a button or any other part of the interface that can be reached only by clicking or dragging the mouse is inaccessible for users of screen readers or those with motor impairments who use the keyboard to navigate the screen. (Many other alternative input devices convert their signals to keystrokes, so making an application keyboard accessible is a good way to make it accessible to people using other input devices as well.) In technical terms, the scripts triggered by a user event such as a mouse click or keystroke are known as event handlers. Some event handlers work by clicking or moving the mouse; examples are the mouseover and mouseout events commonly used in scripting rollover buttons. These are known as device-dependent event handlers because they require a specific device in order to work. Since people with disabilities use such a wide variety of devices, these device-dependent event handlers can cause many accessibility problems. Fortunately, substitutes can often accomplish the same thing in a device-independent way that is, they make no assumptions about the kind of device used. Using device-independent event handlers is a Priority 2 item in WCAG 1.0. (Checkpoint 9.3 reads, "For scripts, specify logical event handlers rather than device-dependent event handlers. [Priority 2]") Here is the source code for a rollover event on the Knowbility site. <script language="JavaScript"> <!--function MM_swapImgRestore() { //v3.0 var i,x,a=document.MM_sr; for(i=0;a&&i<a.length&&(x=a[i]) &&x.oSrc;i++) x.src=x.oSrc;} function MM_swapImage() { //v3.0 var i,j=0,x,a=MM_swapImage.arguments; document.MM_sr=new Array; for(i=0;i<(a.length-2);i+=3)} </script> <a href="employment.html" onMouseOut="MM_swapImgRestore()" onBlur="MM_swapImgRestore() " onMouseOver="MM_swapImage ('employment_bt','', 'images/employment_bt_f2.gif',1)" onFocus="MM_swapImage('employment_bt ','','images/employment_bt_f2.gif',1)"> <img name="employment_bt" src="/books/3/135/1/html/2/images/ employment_bt.gif" width="109" height="34" border="0" alt="Employment"></a> The script above includes both device-dependent event handlers (onMouseOver, onMouseOut and logical ones (onBlur, onFocus). The redundancy is necessary because onFocus and onBlur are not truly device-independent. As a result, navigating the page with either the mouse or the tab key will move us consecutively from one graphical link to the next. Landing on the link triggers the event handler, which replaces the orange image with an otherwise identical yellow one; the ALT text announces the link destination. In this case, the change in background color is achieved through swapping images. As we'll ex-plain below, this effect could be achieved just as effectively by using Cascading Style Sheets (CSS). This brings us to the second aspect of making rollover buttons accessible: ALT text. We do not know of any way to associate ALT text with the "swap image," that is, with the image that replaces the image that "receives" the user event. It's crucial, therefore, that the ALT text for that initial image be both meaningful and self-sufficient, since people using screen readers, talking browsers, refreshable Braille displays, or text-only displays will not hear the images of text so fre-quently associated with rollovers. This is why Kara Pernice Coyne and Jakob Nielsen recommend against using rollovers to convey "any information" in their 2001 report, Beyond ALT Text. Note that the ALT text in the code above corresponds exactly to the named link. JavaScript is great stuff, and Web authors have shown great imagination in using these capabilities to create highly functional and useful Web-based information. But some user agents cannot handle scripts: the text-only browser, Lynx, is one example, and screen readers such as JAWS and Window-Eyes often have difficulty with scripted pages. Support for scripts is sometimes disabled in public-access computer facilities and school computer labs and in some house-holds. This is why WCAG 1.0 Checkpoint 6.3 requires that pages work when scripting is turned off or, when that isn't possible, that developers provide an equivalent alternative. Alternatives to Scripts The <noscript> element was developed as a way to provide content in an alternative manner. If the user agent supports scripts, then the scripted events that accompany the HTML document will run (assuming that the scripting is correct, of course!). If scripts are turned off or not supported by the browser, however, then the <noscript> element (if present) determines how content should be presented. In the absence of the <noscript> element, results may be unpredictable: the browser will search for the next valid HTML element or other statement it is capable of processing. On the Knowbility page shown in Figure 14-1, if scripts are turned off or not supported, the functions are delivered through HTML elements that do not require scripts (Figure 14-2). Figure 14-2. Screen shot of the Knowbility home page with scripts turned off. Accessed January 11, 2002, at http://www.knowbility.org. Used with permission.  When scripts are turned off, navigating the Knowbility home page with the mouse or the tab key no longer results in the same color change behind activated links that occurred when scripts were enabled. However, the links still work: we get meaningful ALT text, and all functions are delivered via HTML. Since the browser ignores the JavaScript instructions it cannot recognize when scripts are turned off, it simply continues until it finds HTML code it can render. In this case, the browser starts with the anchor tag, skips the now useless JavaScript statements, then locates the image element and its alt at-tribute. In other words, the browser behaves as if the source code actually contained only the following code. In fact, this is the actual source code from the page, and we have simply removed the JavaScript statements. <a href="employment.html"> <img name="employment_bt" src="/books/3/135/1/html/2/images/employment_bt.gif" width="109" height="34" border="0" alt="Employment"></a> Look, Ma, No Scripts! (And No Images, Either) There's a way to produce an identical visual effect without using either graphics or scripting. This method involves creating text links, then using the CSS background-color property to set the background color for the link and to change it with a CSS "pseudoselector" called :hover when the mouse moves across the link text. The style sheet might look something like the following one, which uses the :hover pseudoselector instead of JavaScript to change the background color and size of a link when the mouse passes over it. a{background-color:orange; color:black; font-family:arial,helvetica,sans-serif; font-size:100%} :hover{ background-color:yellow; color:black; border:thin,ridge,outset; font-family:arial,helvetica,sans-serif; font-size:125%} This simple style sheet does two things. First, it "styles" the <anchor> element (<a>), the essential element for hyperlinks. As a result, link text will be displayed in Arial or another available sans serif font, using the browser's default font size; the text will be black against an orange background. The effect of the :hover pseudoselector will be (1) to change the background color to yellow and (2) to enlarge the font by 25 percent whenever the mouse "hovers" over the link. Like the JavaScript rollover, these stylistic changes make it easier for users to tell when the mouse has entered a clickable area. Because there are no images to load, there is no need to write ALT text (and no possibility of forgetting to do it!), and the page will load faster as well. (For more information about using CSS to support maximum accessibility, please see Chapter 15.) Using the <noscript> Element A user's ability to identify and use links on the Knowbility site is not affected by the presence or absence of JavaScript support. But where JavaScript is essential for functionality, it's necessary to provide access to equivalent functionality or to the information generated by that functionality, as WCAG 1.0 and Section 508 require. In that case, you should follow the JavaScript with an opening <noscript> tag and then enter the alternative content. You must close the <noscript> element with an end tag (</noscript>) when you have delivered the alternative content. It is important to note that the alternative content may include graphics files and links; in fact, it is this capability that gives the <noscript> element its power. Imagine that we have a Web page that enables a user to get information about what garden plants to grow at what time of the year, de-pending on geographical location. Various functions are enabled as the user enters and evaluates information, creating a dynamic experience. For maximum accessibility, the <noscript> alternative would include a description of these functions and perhaps a graphic image for browsers that do not support JavaScript. Here's an example of code that uses the <noscript> element to provide equivalent alternative content on our gardening site. <noscript> <IMG src="/books/3/135/1/html/2/garden.gif" alt="garden of blooming flowers and shrubs"> You are visiting the Interactive Gardener, a dynamic instruction site that provides information for planting various garden plants. Visitors using JavaScript-enabled browsers can answer questions about their location, soil type, and plant preferences for customized information about garden plants best suited to their interests. For our other visitors, we provide more general information about planting seasons in various parts of the US on our <a href="http:// www.usgardenersalternative.com"> alternative gardening information </a> site. </noscript> This is an acceptable alternative, but the alternative information provided is not strictly "equivalent," since it does not have the same dynamic nature as the site that uses JavaScript. An even more useful alternative would be to have a server-side script collect the same information by means of a form and return the results to the user. The time lag would be greater, but the full function could be delivered by alternative means. The Olympics Committee Leaves Out Millions Again! One thing that is not acceptable is simply to tell visitors they are out of luck if they don't use JavaScript, as was recently done, to much no-toriety, on the Web site of the 2002 Salt Lake Olympic Winter Games, found at http://www.saltlake2002.com. We need to make a side observation here about our use of screen shots of the actual Web sites of real organizations. Throughout this book, we used many real-world examples to illustrate the barriers encountered by millions of users with disabilities every day. As we contacted businesses, agencies, and institutions to seek permission to reprint illustrations of their sites, we were generally met with cooperation and interest. Several of them, including Austin's Capital Metro, actually changed their sites to be more accessible. The folks in charge of the Olympics seem to feel that if they simply ignore the problem of accessibility, it will go away. After several exchanges and our inclusion of edits requested by them, the people in charge of granting permission to reprint images of the 2002 Olympic Winter Games site simply stopped responding to us. As a result, we will describe what we found on the site without the benefit of illustrations. In February 2002, the home page of the 2002 Olympic Winter Games contained a horizontal purple header with the Winter Olympics logo and the words "Salt Lake 2002 Official Site of the 2002 Olympic Winter Games." The ALT text, however, simply said "Salt Lake 2002." An ad promoting a contest appeared at the top of the page. The only ALT text provided said, "Click here." This was worse than useless it was actually misleading since it created the impression that the user had to follow the link in order to "enter" the Olympics site. Navigation links were presented by means of a segmented gold bar that ran horizontally beneath the logo space. The link categories were the following: Sports. Schedules. Athletes. Spectator Info. Shopping. Games Programs. Tickets.
Each segment opened into a cascading menu of nested links activated through JavaScript. For example, the Spectator Info category pulled down a menu with links to FAQs, specific information about accommodations, tickets, weather, and other useful facts for visitors. Within each pull-down menu, nested subcategories provided greater detail about each item. Such cascading menus are problematic for people using screen readers; Coyne and Nielsen [2001b] have reported that cascading menus also posed problems for test participants who used screen magnifiers and may cause problems for others with low vision who use high-contrast settings in their browsers or operating systems (for example, in the Windows Accessibility Options control panel). You might have assumed that the Salt Lake Olympic Committee would have learned from the outcry over the inaccessibility of the site for the 2000 Olympics in Sydney, Australia. As we mentioned in Chapter 3, a complaint to the Australian Human Rights and Equal Opportunity Commission by Bruce Maguire in 1999, 15 months before the games began, resulted in a damage award of $20,000 (Australian) to Maguire. The judgment also forced the Sydney Organizing Committee for the Olympic Games (SOCOG) to hire IBM, which had built the site in the first place, to retrofit it for accessibility at a cost SOCOG estimated at $2.2 million (Australian). The Equal Opportunity Commission rejected SOCOG's outlandish cost estimates and ordered that the changes be implemented. Clearly, though, the torch of accessibility awareness was not passed along to the 2002 Salt Lake committee. The problem this time was not a complete absence of ALT text (although the ALT text on the 2002 Olympic Winter Games site was often a meaningless "Click Here"). The most astounding aspect of the 2002 Winter Olympics site was that a user with JavaScript turned off or not supported was redirected to a page that was completely blank except for the message "This site requires javascript [sic] enabled on your browser." To make matters worse, the JAWS screen reader was unable to report this message users who couldn't see the message were simply left hanging, with no idea why their screens had gone suddenly silent. When we explored the 2002 Olympic Winter Games site to discover reasons for such heavy reliance on JavaScript, we found frames throughout that were written by means of the JavaScript document.write command. This gives developers the flexibility to generate a different number of frames on different pages. JAWS reported that there were four frames on the home page, for example, six on the Sports page, two on the page about the Olympic Torch Relay (which opened without warning in a new browser window titled, interestingly enough, "2002 Chevrolet.com"), and seven frames on the page for the Paralympics (formerly the Special Olympics). But there were no <noscript> element alternatives for users whose browsers don't support JavaScript and there weren't any <noframes> element op-tions, either, for people whose browsers don't support frames. Nor did the existing frames have names that would be meaningful to users, as WCAG 1.0 Checkpoint 12.1 and Section 508 paragraph (i) require. The main page for the Paralympics site, for example, had three frames, called "Top," "Middle," and "Bottom." We found no reason why the developers couldn't have written their scripts to generate meaningful names for these frames. Of course, that wouldn't remove the barriers for people whose browsers don't support JavaScript. Activating the Sports link (one of the top-level links on the home page menu bar) took us to a new page that listed the submenu items as graphic links. These were not highly interactive pages. There was no increase in functionality offered by the reliance on scripting, no whiz-bang application that could have been offered in only this way. We must infer that simple thoughtlessness about the accessibility of their pages led the developers of the 2002 Olympic Winter Games site to create the unnecessary barriers we encountered there. The <noscript> element could have easily been used to include a link to HTML pages that delivered the same content to nonscript-enabled browsers. The JavaScripted pull-down menus provided link choices on that one page that were also available as graphic links on subsequent pages. The additional functionality offered was merely the ability to skip a link step hardly worth locking significant numbers of people out of the ability to navigate the site at all. Simple HTML links within a <noscript> element could have made all this information available to users who cannot or do not use JavaScript. Perhaps the developers of the 2002 Olympic Winter Games site were operating on the assumption that current versions of the most popular screen-reading software do support JavaScript. This is a correct assumption. It by no means follows, however, that because the software is available everyone owns it. Many individuals, schools, and organizations that provide services to people with disabilities are still using older software. There are also many others who deliberately choose to work with scripting disabled, for a variety of reasons. While there are those among our colleagues who insist that not supporting JavaScript is equivalent to hanging on to your rotary phone too outdated to justify we do not agree. We believe that technology is not yet sufficiently disseminated throughout society to allow us to deny access to information to those who are lagging behind current technology applications. The bottom line is that, with or without ALT text, users of screen readers or other assistive technologies that do not support JavaScript were denied access to any information whatsoever about the 2002 Olympic Winter Games on the "Official Site." Even information about the Paralympics schedule, the competition for athletes with disabilities, was completely inaccessible to anyone whose browser was not JavaScript-enabled! We can only conclude that the Olympics site was designed without input, testing, or feedback from users with disabilities. Indeed, the designers must not have even tested the site on a Mac. WebReference.com's Andy King [2002] described the numerous JavaScript errors that interrupted his visit to the Olympics site from his Mac. Thinking to avoid the pesky, repetitive error messages, he turned off the scripting and was locked out of the site entirely! This is an extreme example but not an uncommon one. The lesson to take away from Salt Lake City is that, in designing for maximum accessibility, the developer must ensure that the functionality and, most important, the content of the page does not depend solely on scripts. |
