| OK. You get the point, and now you're ready to move on to a solution. What are you supposed to do? This is where Web accessibility guidelines and standards come in. Throughout this book, you will find references to both Section 508 and WCAG 1.0. These guidelines and standards aren't just "rules" that you have to follow in order to avoid getting into trouble. They can offer valuable insight into some ways of addressing the problems we've been discussing, in order to make these online schedules more usable and accessible, not just for people with disabilities, but for everyone, without the trouble and expense of creating and maintaining two (or more) versions of the same site. Applicable Section 508 Standards For example, Section 508, Chapter 1194.22 (g), makes a succinct statement about tables, as follows: "(g) Row and column headers shall be identified for data tables." This is the technique we saw in the code fragment for the Babylon Village train schedule above. But we also saw that the <th> element by itself may not be enough to help readers grasp complex schedule information. This is why paragraph (h) adds a further requirement: "Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers." WCAG 1.0 Checkpoints 5.1 and 5.2, upon which these standards are based, provide essentially the same requirements for marking up a table correctly. If the developers of the Babylon Village train schedule had used the type of markup specified in paragraph (h), screen readers would be able to tell Long Island Rail Road passengers not only where the train would be at 7:31 but also whether it was headed for Babylon Village or Penn Station information that is no longer visually available on the screen. Screen readers and talking browsers "transform" tables into synthetic speech, and the accessibility guidelines urge us to create pages that "transform gracefully," an admonition that is, no doubt, subject to debate. But at the very least it means that it has to be possible to listen to the table and understand it, without having to strain any harder for that understanding than is absolutely necessary. At best, it ought to mean that people with disabilities are able to draw upon contextual and circumstantial information in their efforts to read the table, much as people without disabilities do; someone with a disability should not have to experience him- or herself as making an effort to figure out what time the bus is coming or at least no more of an effort than someone without a disability. In Section II, you will learn coding techniques for creating tables that allow such ease of use. Other Applicable WCAG 1.0 Checkpoints WCAG 1.0 goes beyond the two points mentioned above. Two other checkpoints under Guideline 5 come into play here as well. While you will learn about these in some detail in Section II, it is worth mentioning here other attributes that can make tables much easier to use. Checkpoint 5.5: Provide Summaries for Tables Checkpoint 5.5 suggests providing a summary for the table itself. The <table> element's summary attribute is designed for this purpose. You might think of the summary attribute as an alt attribute for a table. It serves as a description for the entire table. The summary attribute should not be confused with the <caption> element: the summary attribute does not appear on the screen, but the <caption> element does. Since the <caption> element does appear on the screen, you can use it to identify the table and its purpose, while the summary attribute helps people using screen readers, talking browsers, or refreshable Braille displays understand how the table is organized. (See Chapter 11 for further discussion of table summaries and captions.) Checkpoint 5.6: Provide Abbreviations for Headers Checkpoint 5.6 suggests using the abbreviation element (<abbr>) to help people using screen readers and talking browsers make sense of the terse abbreviations that are sometimes imposed on designers by the visual constraints of the screen. This would clearly be very helpful for riders trying to determine which intersections the bus crosses. Unfortunately, current browsers and screen readers do not appear to support the automatic expansion of the <abbr> and <acronym> elements. (Expansion, in this context, means that the screen reader or talking browser speaks the full name instead of the abbreviation.) But that doesn't mean you have to give up on this point. Designers of the bus schedules on the Santa Clara Valley Transportation Authority site, which we will examine next, used a separate table of abbreviations to identify intersections whose names are abbreviated in the schedule itself. Checkpoint 11.2: Avoid Obsolete Features of HTML But of course none of this would work at all on the schedule pages on the Capital Metro site (as it appeared when we visited it in June 2001). As noted earlier, these schedules are not constructed as HTML tables at all but are instead set up as preformatted text using the <pre> element, which does not support any of the features discussed above. This use of the <pre> element might have been appropriate prior to the introduction of the <table> element in early drafts of the HTML 2.0 specification. Use of the <pre> element on the Capital Metro site in 2001, however, would fall under WCAG 1.0 Guideline 11, and especially Checkpoint 11.2: "Avoid deprecated features of W3C technologies [including older versions of the HTML specifications]." The <pre> element would be considered a "deprecated" or obsolete feature for the purposes of presenting a bus schedule because it has been superseded by the <table> element. Guideline 3: Distinguish Content and Structure from Presentation and Layout In fact, the editors of WCAG 1.0 make exactly this point in explaining the recommendation (Guideline 3) that designers separate content and structure on the one hand from presentation and layout on the other. Elements like <pre> and <font> are presentation elements, while elements like <ol> (ordered list) and <table> identify structural components of the document or their place in its logical organization. The editors write that "using presentation markup rather than structural markup to convey structure (for example, constructing what looks like a table of data with an HTML <pre> element) makes it difficult to render a page intelligibly to other devices" such as screen readers and other assistive technologies. Guideline 12: Provide Context and Orientation Information Both versions of the Capital Metro bus schedule we saw in May and June 2001 (for sighted and for visually impaired riders) suffer from other problems as well. Neither page has a TITLE element, for example, so the browser window simply displays the URL, which is harder to understand than a title such as "Schedule for Route 7 Duval." This comes under WCAG 1.0 Guideline 12, "Provide context and orientation information." Checkpoint 12.1, which is roughly equivalent to Section 508's paragraph (i), applies specifically to frames (it reads, "Title each frame to facilitate frame identification and navigation"), but it is equally important to provide accurate, meaningful titles for all pages on the site. The Babylon Village schedule page, for example, is clearly titled, "Babylon Village Railroad Schedule" (see Figure 5-9). Guideline 13: Provide Clear, Consistent Navigation WAI Guideline 13, which has no real counterpart in the Section 508 Web standards, stipulates that designers should "Provide clear navigation mechanisms," and goes on to explain that devices such as navigation bars, site maps, and orientation information are not only important for users who are blind or visually impaired but also helpful for all users. Consistency, the WAI adds, is especially vital for people who have cognitive difficulties (Checkpoint 13.4). This is one of those things that seems almost self-evident now: of course there should be navigation bars! But there are no navigation mechanisms at all, and no embedded links, on the Capital Metro schedule pages we examined earlier in this chapter (see Figures 5-2 and 5-6); riders are entirely dependent on their browser's Back button or History functions. We can see that transportation sites are particularly challenging. Let's wrap up the chapter by looking at one site that successfully incorporates many of the features we have mentioned and one that tries an unconventional approach with limited success. Partway Home: The Santa Clara Valley Transportation Authority The Santa Clara Valley Transportation Authority offers riders a choice among multiple versions of its bus schedules. The site indicates that, besides the schedule that most people use, schedules are available in "ADA accessible" and PDF versions, and there is even a map in Firepad format that enables a graphic interface for the Palm Pilot! (See Figure 5-11.) Figure 5-11. Screen shot of Santa Clara Valley Transportation Authority (VTA) page listing available schedules for bus route 12. Accessed June 9, 2001, at http://www.vta.org/schedules/SC_12.html. Used with permission.  This interesting approach was somewhat compromised by the fact that the navigation bar on this and all pages on the Santa Clara Valley Transportation Authority site was coded in such a way that people using Internet Explorer and JAWS were forced to listen to a rapid-fire reading of a Javascript Routes menu in the left navigation bar that lists the numbers for every route in the transportation system including regular buses, express buses, shuttle buses, and light rail! unless they caught the Bypass Navigation link right at the beginning of the page and thought fast enough to use it. You had to miss that link only once to understand how important it was. And although the Santa Clara Valley Transportation site has now corrected the problem we've just described, you have to encounter only a few pages like this one to understand how fragile such accessibility workarounds can be. That is, Skip Navigation links are workarounds almost by definition they're usually add-ons like wheelchair ramps attached to older buildings, not integral to the original design. Looking at a Typical Schedule: Route 12, Eastbound, Saturdays Table of Abbreviations. The Saturday schedule for eastbound Route 12 is typical of the thoughtful way this site presents route and schedule information. The screen shot in Figure 5-12 shows a page with two tables. The first spells out the full names of the intersections whose abbreviated names are listed at the top of the schedule; this strategy compensates effectively for the lack of browser support for the <abbr> element. Figure 5-12. Screen shot of the Saturday schedule for the Santa Clara Valley Transportation Authority's eastbound Route 12. Accessed June 9, 2001, at http://www.vta.org/schedules/SC_12EA_SA.html. Used with permission.  The Bus Schedule. The bus schedule, which is contained in the second table, appears below the table of abbreviations. The abbreviated names of the intersections are on the top row. The next line says that "PM times are shown in bold." (These afternoon and evening times are not distinguished in any other way, however, so this important information is lost on people using screen readers and talking browsers. By contrast, the Babylon Village train schedule includes the "am" and "pm" designations as part of the schedule data.) The third line repeats the identifying information for the route. The next row is the first line of the actual schedule and shows the time when the bus will reach each intersection. Viewing the Source. The second table, which presents the schedule, is formatted as a complex table, using the <thead> and <tbody> elements as well as the <tr>, <th>, and <td> elements found in HTML's simple table model. This allows people using screen readers and talking browsers to stop on any timepoint and determine what intersection is associated with it. If you access this schedule with JAWS, you might get to a timepoint and find yourself unable to figure out where the bus would be at that moment. You might hear something like the following: Ten oh two ten seventeen ten twenty four ten twenty seven ten thirty two ten forty four ten thirty two ten forty seven . . . The designers have made it easier for sighted riders to run their eyes up and down the columns by shading every other one. Without an equivalent way for riders with visual or cognitive impairments to identify a relationship between a given number and a specific intersection, the schedule would be meaningless garbage. But there is a way this time, as there was not on the Capital Metro site the first time we tried to use it. The designers have used HTML features that make it possible to get auditory information about the association between a timepoint and an intersection. You can stop when JAWS says, "ten forty seven," for example, and ask JAWS to tell you where you are. It will respond, "Row 5. Column 2. King Berry. Ten thirty two. Ten forty seven." First JAWS tells you where you are in the table at row 5, column 2. Then it reads the abbreviation for the intersection: King Berry, which the table of abbreviations expands to King and Berryessa. Then JAWS reads the first timepoint on this row, ten thirty two the time at which this particular bus sets out from the Civic Center and finally repeats the timepoint where you had stopped reading through the schedule. Of course it takes far less time to do all this than to read about it here. What we have just described appears to be the default for the way the JAWS screen reader responds to the combination of the <thead> and <tbody> elements with the more common <tr>, <th>, and <td> elements. Specifically, it reads the contents of the <th> element at the head of the current column, then the contents of the first cell (<td> or <th>) in the current row. The screen shot in Figure 5-13 shows a portion of the source code for this table, including the <thead> element and several rows of <th> elements within the <thead> element. Figure 5-13. Source code showing the use of the <thead> element in the Route 12 bus schedule. Accessed June 9, 2001, at http://www.vta.org/schedules/SC_12EA_SA. html. Used with permission.  Loose Ends. But there's a little fly in the ointment. We went back to the page that lists all the different schedules available for this route and selected the ADA Accessible Version link. The schedule wasn't there! Instead, as shown in Figure 5-14, we got a message that said, "The document you seek no longer exists or is no longer current. Please refer to the link homepage for current information." (Screen reader note: JAWS automatically inserts the identifier, link, whenever it encounters a link. When "home page" is run together as one word, JAWS pronounces it as hahhmipage.) Figure 5-14. Screen shot of the page announcing that the ADA accessible version of the Route 12 bus schedule "no longer exists or is no longer current." Accessed June 9, 2001, at http://www.vta.org/schedules/12EA_SA.html#body. Used with permission.  This was very disappointing. What happened, we assumed, was that a recent redesign had made a separate, ADA accessible version redundant. We thought this was a good thing, of course exactly the practice we advocate in this book! We assumed that someone had forgotten to update the page that listed the available schedules to reflect the change. This last step is essential: a blind person or someone with a cognitive impairment who really needed this schedule in order to plan his or her day would probably have selected the ADA accessible schedule first and might well have given up when he or she heard that the page no longer existed. After all, he or she would have assumed that the other schedules listed would not be accessible. But our assumption was wrong. On a subsequent visit to this site, the ADA Accessible Version link led to a page that provided information in a "narrative" format: "From terminal on First Right onto Taylor Right onto Miller Right onto Mission," and so forth. [3] It's extremely helpful to have this little narrative about the route. However, this is not actually an alternative version of the schedule: in order to find out the actual times when the bus should reach a given intersection, you have to return to the schedule we've been discussing. As we'll explain further in Chapter 8, this sort of problem occurs frequently as a result of well-meaning attempts to address accessibility concerns by providing multiple, variant versions of the "same" information: all too often, the information isn't the same, and the discrepancies can lead to confusion and frustration both for site designers doing their best to do the right thing and for people seeking information they need. [3] Accessed May 24, 2002, at http://www.vta.org/schedules/SCA_12_DIRECT.html#.
An Unusual Approach: Tri-Met Public Transportation for Portland, Oregon The Tri-Met site, available at http://www.tri-met.org/home.htm, is an unconventional design that aims for compatibility with all browsers, including text-only browsers such as Lynx. Route information includes narrative route descriptions as well as links to connecting routes. The schedule format avoids tables in favor of a simpler format that lists the names of intersections (fully spelled out) down the left-hand side of the page; the times for each intersection are listed on the line that begins with the name of the intersection. This makes it very easy to determine the schedule for any given intersection, but it is more difficult to understand the complete schedule for an individual run. However, using the site's trip-planning form may solve this problem (Figure 5-15). Figure 5-15. Screen shot of the trip planner on the Tri-Met public transportation system for Portland, Oregon. Accessed June 16, 2001, at http://go.tri-met.org/cgi-bin/plantrip.cgi. Used with permission.  Unfortunately, the form's fields are not properly labeled but that's a topic for another chapter. We'll discuss some of the challenges associated with forms in Chapter 8, and we'll show you some solutions in Chapter 10. In the next chapter, we'll explain the business case for accessibility. |
