The Trouble with Tables

The Trouble with Tables

The trouble with tables is that they're meant for the eye, not the ear. They also make significant cognitive demands. To understand a table, you have to be able to read in two dimensions (horizontal and vertical, x and y ) simultaneously , matching up the contents of individual data cells with row and column names that often provide only slender clues about the relationships the data embody.

Web designers aiming for maximum accessibility have to understand and address these challenges. People who rely on screen readers and talking browsers—including both people who are blind or visually impaired and people with cognitive difficulties such as dyslexia— have to hold row and column headers in their minds as the screen reader reads from cell to cell across each row. As the screen reader moves down from one row to the next , it becomes harder and harder to remember those row and column headers; the table sounds more and more like a list of meaningless numbers .

People with disabilities aren't the only ones who have trouble understanding tables. Design guru Edward Tufte has spent much of his career demonstrating how hard it is to understand the visual display of quantitative information—and how devastating the consequences of poorly designed information displays can be. The explosion of the space shuttle Challenger in 1986 is his case in point. Tufte argues that poorly structured charts made it difficult for NASA decision makers to grasp the strong correlation between low temperature and O-ring failures like the one that caused the fatal fuel leak aboard the Challenger. The following examples aren't quite so dramatic, but it is worth keeping in mind that many people rely on the information presented in tables to make routine decisions that affect their day-to-day lives—looking up bus schedules, for example.

User Experience Narrative: Austin's Capital Metro

Like most other people who are legally blind, I (John) do not drive, depending instead on rides from my spouse, colleagues, and friends , as well as taxis and the city's bus system. I needed to get downtown for a meeting, so I thought I'd visit the Capital Metro Web site and look up the schedule for Route 7 Duval, which passes near my home and continues downtown past the University.

When I reached http://www.capmetro.org I thought I had struck paydirt. The Capital Metro site actually had a link on its Routes and Schedules page labeled Schedules for the Visually Impaired! Delighted by this evidence of a commitment to accessibility, I pressed the enter key on my keyboard to follow the link.

Dazed and Confused

I was bewildered by what happened next . The page I came to was a simple, unformatted list of all the files in the directory (folder) on the Capital Metro Web server where the schedules are stored. We're usually not meant to see these listings—they appear only when the browser points to a directory that doesn't include a file called index.htm or index.html , which most Web servers are programmed to display by default if no other filename is specified in the URL. Some servers are set up to use other default filenames ( default.asp, for example). In any case, these occurrences are relatively rare; most directory listings are protected against unauthorized viewing.

Capital Metro's directory listing page of routes and schedules files was headed www.capmetro.org/VIEW/_Routes/ — the name of the directory/folder that contained the schedule files, and this was what the

JAWS screen reader read to me. The rest of the page listed those files as links. The files were listed in alphabetical order, but most of the filenames began with the words dillo (a free trolley service for commuters and shoppers) or route (the Capital Metro standard bus system). The first word in the filename was followed by an underscore, a number sign (#), another underscore , and then the actual route number, so I had to go through quite a few filenames before I found what I was looking for. Figure 5-1 shows a screen shot of the directory list- ing. If you look closely, you'll see that I had to scroll even farther than you might think because the filenames are not sorted in what most ordinary people would think of as alphabetical and numerical order. An ordinary person might assume that route_#_6 would be followed immediately by route_#_7 . But in this sorting scheme (which is conventional for computer directories), route_#_6 is followed by route_#_61, then route_#_62, and so on.

Scrolling through the links shown on the screen, I eventually found the schedule for Route 7. I pressed the enter key to follow the link. The next thing I heard was something like this:

Route number colon 7

Route name colon 7 dash Duval 27 dash Dove Springs

Saturday

Northbound

I then heard the words "Aberdeen slash Rundberg," followed by a stream of numbers read without pause or punctuation:

Seven twenty six seven thirty seven fifty seven fifty-seven . . . and so on.

After several lines of this, I heard something I recognized as the name of an intersection, followed by another stream of numbers . As shown in Figure 5-2, the numbers were evidently times when the bus was due to cross the intersection—but there were two problems.

The first problem had to do with my own geographical orientation to Austin, where I've lived for over 20 years . What I now recognized as the first intersection listed on the page (Aberdeen Way at Rundberg Lane) is in North Austin. The next intersection listed, at Second and Congress, is in downtown Austin, more than eight miles to the south of Rundberg Lane. But the schedule was for the northbound run. So I felt geographically disoriented.

The second problem was that there was no way to tell what the numbers represented, no way to use the format to identify the association of the timepoints with any intersection whatsoever. Pressing the keystroke (Alt+Ctrl+NumKeypad5) that allows JAWS users to iden- tify the current location in a data table, together with associated column and row headers, if any, produced only the report "row zero column zero" (the coordinates for the upper-left corner of the screen). Since I was clearly not at that screen location, this meant that I wasn't in a table at all.

Viewing the Source: The Route 7 Schedule for People with Visual Impairments

I next decided to look at the source code for the page in order to learn why I was having so much trouble with it. The first thing I found was that instead of putting the schedule information into an HTML table, the site designers had used an old and now mostly outmoded tag, <pre>, which allowed Web developers in the early days (before 1994) to preserve layouts (including tables) that were too complex for HTML to manage at that time. The screen shot in Figure 5-3 shows part of the source code, including the <pre> tag.

Visually, the source code is actually more legible than the Web page shown in Figure 5-2. But that is hardly the point, and in any case the source code is just as difficult to understand for someone using a screen reader or talking browser.

A Deliberate Arrangement

The Web pages we've been discussing were published in a genuine effort to make information about bus routes and schedules accessible to riders who are blind and visually impaired. It's worth noting that the <pre> tag is not what differentiates the schedule for visually impaired passengers from the one designed for Capital Metro's sighted riders; the <pre> tag was used in both situations, as you'll see later in Figure 5-6.

A Table Listing Routes and Schedules

The main link to the Current Schedules and Maps page from the Capital Metro Routes and Schedules page led to a route listing that was formatted quite differently, using an HTML table (Figure 5-4).

This table was not as easy to follow as it could have been, but it was far easier to locate the link to the schedule for Route 7 than it was on the page specifically intended for visually impaired riders (see Figure 5-2)—and it really was a table. The route numbers functioned as links to the page that displayed the corresponding schedule information. Therefore, people using screen readers could locate a chosen route. Using the Links List feature in JAWS, for example, allowed me to get there quickly, as shown in Figure 5-5.

So far, so good. However, the schedule attached to this link (as shown in Figure 5-6) was no harder for someone using a screen reader to manage than the one we discussed a moment ago—but it was actually different from the schedule that visually impaired riders saw or heard.

Differences Between the Current Schedule and the Schedule for Visually Impaired Riders

The schedules for sighted and visually impaired riders were different in three important ways.

1. The schedule for sighted riders displayed the weekday schedule first, whereas the schedule for visually impaired riders showed the Saturday schedule first.

2. The schedule for sighted riders displayed information about the southbound route first, whereas the schedule for visually impaired riders showed the northbound route first.

3. The schedule for sighted riders appeared to list more timepoints than the schedule for visually impaired riders.

These differences added up to a violation of an important principle of accessibility. The Capital Metro site did not provide equivalent access to the information necessary to make decisions about bus travel across the city.

We Have to Stop Meeting Like This

Our encounters with the Capital Metro site took place in late May and early June 2001. In early July, however, Capital Metro officials and Web developers met on two different occasions with us, with other representatives of Knowbility, Inc., and with a group of passengers who are blind. The meetings explored the challenges we have described and discussed a range of short- and long-term solutions. The short- term results are promising : in August 2001, Capital Metro revised both its timetables and their presentation on the Web site. The new version is a distinct improvement. The schedule shown in Figure 5-7 is for Route 7—the same route we examined earlier. The schedule has now been formatted as an HTML table, with the abbreviated names of intersections defined as column headers that can be recognized by assistive technologies. (We'll discuss the techniques below and explore them more thoroughly in Chapter 11, where you'll learn to create accessible tables.)

As gratifying as were the meetings with Capital Metro staff and the results they achieved, one of the purposes of this book is to make Web accessibility more widely accepted. While we sincerely appreciate the effort made by Capital Metro's staff members once they understood the issues, it should not be necessary for local advocates to meet with every public service company in order to gain access to information. More professionals are coming to understand the need, the benefits, the tools, and the techniques of accessible design, and as this information is more effectively shared, we can all stop meeting like this.

More improvements are expected in future updates to the Capital Metro site. Perhaps most importantly, these meetings opened up a new line of communications between the transportation system and an important customer group that will lead to continuing improvements in the way riders experience the quality of the city's public transportation system.