Skip Navigationtrace.wisc.edu HelpSearchBottom of Page

Working on Accessible Web Content Guidelines and Designing More Usable Documents

Compiled by:

Mark Novak
Project Engineer
Trace R&D Center

July 2001

Abstract:

Many individuals, especially those with visual, physical, and/or cognitive disabilities, have trouble navigating the content of data tables on the World Wide Web. These problems exist because most browsers do not allow keyboard navigation of the data tables, which is an essential technique used by many people with disabilities whether or not they use assistive technology (AT).

Background:

The Trace R&D Center had already developed the "First Unified Web Guidelines"  (Vanderheiden, G. C., & Chisholm, W., 1997) to assist developers with disability access concerns when the World Wide Web Consortium (W3C) launched the International Web Accessibility Initiative (WAI). Trace Center Director Gregg Vanderheiden and staff human factors engineer Wendy Chisholm soon joined the WAI's Web Content Accessibility Guidelines (WCAG) group as co-editors. The working group encountered several challenges, one of which centered around how to provide access to web-based data tables.

Trace began the research by reviewing the "state-of-the-art" in table accessibility and developed techniques that would allow users to navigate web-based data table header information and cell content using the computer keyboard with the browser alone, or in combination with AT.

Objectives:

The goal of this project was to determine what "technology" would allow users with disabilities to both navigate and access the contents of the web based data tables. The technology solutions would then be added to the WAI content guidelines and shared with the AT field.

Results:

First, a javascript tool was developed that demonstrated how web-based data table column headers and cell content could be navigated with a standard browser using the keyboard or AT. The development of this javascript tool provided a reference example, and contributed greatly to the WAI Web Content Accessibility Guidelines (WCAG) 1.0.

Second, the development and availability of the javascript tool, as well as the development of a related tool called HelpDB (help da browser), generated interest among AT developers to improve access to data table information. These tools led to the development of several more robust commercial products to navigate web-based data tables. And these products, in turn, advanced the accessibility of navigation features, such as lists of links, and improved the users web navigation ability and content understanding.

Finally, with the last proof-of-concept dynamic link library (DLL) tool, we were able to construct a side panel for display similar to the "history" or "favorites" functions of Microsoft's Internet Explorer. This may have important implications for the future of electronic document navigation. The ability to provide the user with side by side panel(s) (e.g., multi-views), but with a differing "structured" view(s) of a web page may greatly aid those with visual as well as cognitive disabilities to better understand and navigate an electronic document. To date, we've only briefly looked at what other developers are attempting in this area. Further work may help address navigation issues for multiple disabilities.

Note:  The Web Content Accessibility Guidelines (WCAG) 1.0 became a W3C Recommendation on May 5, 1999.

In addition, HTML 4.0, which supports multimedia options, scripting languages, style sheets, better printing facilities, and documents that are more accessible to users with disabilities, was first released as a W3C Recommendation on December 18, 1997, and was the basis for the development of these tools.

Tools, Demos, and Proof of Concepts used for development during this project:

For speed of prototyping, we began using a scripting language to test whether or not a data table could be found and navigated using the keyboard within the web page of a browser. In the current release of the HTML Guidelines, "tables" are not defined as active elements such as links or forms, and therefore a table does not accept keyboard focus when using the "tab" key to keyboard navigate through a web page. We also chose to work with Microsoft's Internet Explorer (IE) browser, because we were able to find documentation on how IE exposes its document object model. We used javascript to gain access to the document object model within Internet Explorer. Once we learned how to gain "programmatic access" to the document object itself, the process of finding the HTML tags, which represent a table, and then developing a scheme to navigate the table, was straightforward. For a good example of a web-based data table, we looked to the Section on Tables in the HTML 4.0 Guidelines themselves, and used one of the tables described therein and shown below.

 

Figure 1

Figure 1: Travel Expense Report [D]

Our fist attempts at navigating this and other web-based data tables proved encouraging.  We continued to develop the javascript approach and eventually made the source javascript available on our site.

A complete description of the table navigation script is included in Appendix A:

While we were developing the table navigation proof-of-concept in javascript, we learned enough about scripting to create other useful web page navigation tools, which were "cousins" of other powertoy-like tools available on Microsoft's web site.

We developed two basic web page powertoy-like tools that can assist the user in understanding the layout of a web page.  Each tool creates a separate pop-up window that contains a keyboard navigable list of either headers or links from the web page in view.  The user can then select items from within the powertoy-like tool and be transferred to that location on the web page.  For example, if the user found a "header" on the web page of particular interest in the powertoy "header listing," she could select that header in the powertoy tool pop-up window, and be taken to that location on the web page.  The user could then review information from her newlocation on the web page. 

The user can invoke both powertoy-like tools on any web page by activating the context menu (shift+F10) as shown in the following screen shot and then selecting either the "links list" or "headers list." Unfortunately, the powertoy-like tools do not update themselves when a new web page is viewed. The user must do this manually.

Figure 2

Figure 2: Screen shot of context menu activated and "Headers List" selected. [D]

Figure 3

Figure 3: Screen shot of Browser window and Headers List window both open. [D]

As we were developing the powertoy-like tools (late 1998, early 1999), there were few, if any, commercial products that provided the user with a simple list of links or headers on a web page. There also were no commercial products that allowed the user to navigate a web-based data table. Therefore, even though we provided a javascript example to prove that data tables could be navigated, there was not a product in the marketplace with this feature. This prompted us to take what we had learned about the document object model in IE, and develop a more robust proof-of-concept tool which could co-exist with a user's AT, and enhance navigation of a web-based table. A more robust tool would not require manual updates when the user changed the web page, or surfed to a new page.

This more robust proof-of-concept tool actually became a working Windows-based prototype program and became known as "HelpDB".  HelpDB works with IE 4 or higher.  When the user launches HelpDB, it in turn launches IE and then communicates with the IE document object model (DOM) using Microsoft's component object model (COM) technology.  Since HelpDB is a program by itself, it resides in its own memory area and has to access IE across process-boundaries on the personal computer when running the Windows' operating system. The requirement for an across process-boundary operation introduced a common problem that is faced when two programs communicate while running under Windows on the PC (there is more than one way to solve this problem, but we chose to start with the out-of-process method, perhaps more typical of standard AT applications). Based on the number of times a program has to cross the process-boundary to share information and/or the amount of information that is needed to be shared, this task itself can be processor intense and thus on older, slower personal computers, also appear time intensive (i.e., possibly slow enough that the user would have to wait for information to be updated in their AT beyond their level of patience).

We understood that the initial HelpDB tool is processor intensive and has a slow response time, however, we continued to develop HelpDB as originally planned, since the need for a more robust proof-of-concept tool was greater than the need for the fastest tool possible. Also, while developing HelpDB, we decided to make use of Microsoft's Speech API (e.g., SAPI) to enable self-voicing features for HelpDB.

Figure 4

Figure 4: Screen shot of HelpDB containing a list of headers and links
on the upper left, from the web page shown in IE on the right side of the screen.
[D]

HelpDB was developed and demonstrated in the Curb-Cuts Room (e.g., special exhibit room) at the California State University Northridge (CSUN) conference in 1999.  We also gave a presentation at the CSUN conference that involved demonstrating the table navigation javascript tool as well as HelpDB.  The presentation titled, "Increasing the Accessibility of the Web through style sheets, scripts, and "plug-ins,"  is available on the Trace Web site. Informal notes recorded from users of these demos are available on this site.

We also demonstrated HelpDB for several software developers attending the CSUN conference, including software developers from IBM Special Needs Systems (SNS). The IBM developers were impressed with HelpDB's ability to keyboard navigate a web-based data table.  One of IBM's main attractions at the conference was their Home Page Reader (HPR) product, a self-voicing browser that was generating a lot of interest in the disability community. At that time, HPR did not allow the user to navigate a web-based data table using the keyboard.  Following the 1999 CSUN conference, IBM contacted Trace to request a working example of HelpDB and a copy of the source code to develop access to web-based data tables in HPR. With the release of version 2.5 of HPR in June of 1999, users are now able to navigate web-based data tables using the keyboard.

In January 2000, Henter Joyce (now part of Freedom Scientific) released version 3.5 of the Job Access With Speech (JAWS) screen reader with keyboard navigable web-based data tables. We also discovered that a previously available tool in the UNIX/Linux community called "Emacspeak" allowed users to navigate web-based data tables using the keyboard. With the availability of these commercial products, there was no need to continue development of HelpDB. However, it remains available for download and for user experimentation in the Navigation and Reading Tools section of the Designing More Usable Documents page.

After the original powertoy-like javascript tool proved that a web-based data table could be navigated, and HelpDB demonstrated a program could co-exist with AT, this phase of the project was nearly completed. The only lingering question centered around HelpDB being an out-of-process application. Therefore, in the fall of 2000, we decided to develop one last proof-of-concept tool that would be in the same address space as IE, or would be an in-process application. The standard method to accomplish this in Windows is to develop a DLL application. The DLL (e.g., tunnel.dll) loads when IE launches, and provides the user with a standard tree-view component which contains a list of headers on the web page. It is similar to the "history" or "favorites" functions of IE as a separate panel next to the content window. Again, it was very easy to gain access to IE's document object model (especially when using the same address space as IE) to intercept and redirect keyboard information as necessary.

Retrieving and presenting information using the DLL approach (e.g., in-process) was certainly faster (as observed), however, the web page information contained in IE's document object model using an in-process versus an out-of-process approach is essentially the same. Developers may want to consider other issues such as security, ease of grabbing input (e.g., keyboard, mouse, etc.) events, prior to determining which approach may be best for an application.

Figure 5

Figure 5: The Screen Shot above of IE with the tunnel.dll (e.g., DLL)
loaded shows a left-hand panel opened containing a tree-view list
of headers for the web page in view.
[D]

As noted above, there are now several commercial tools that provide the user with the ability to navigate web-based data tables. Therefore, we decided to discontinue further development of a full-featured DLL (e.g., one with all the capabilities of HelpDB) because it would duplicate efforts already completed in the AT field. However, this last proof-of-concept tool is also available off the Trace Center Web site for download at the Navigation and Reading Tools section of the Designing More Usable Documents page.

References:

Vanderheiden, G. C., Chisholm, W.,   "Page Author, User Agent and Assistive Technology Guidelines and Issues - Version 8 Unified Web Site Accessibility Guidelines," Trace R&D Center, Madison, WI.

Appendix A:

Table Navigation Script

The javascript that will allow you to navigate through the table can be seen by viewing the source code for the Table Navigation Script page:

Unfortunately, activating the script can be tricky. First of all, success depends on the browser. The best browser by far for this script currently is Internet Explorer 5. Internet Explorer 4 works, with the following instructions, and Netscape has been known to work, but with much more work. Since tables are not active elements like links, we have been unable to create a mechanism to give a table focus (that seems to work consistently). It may take a few tries, but we seem to have the most luck when we use the following voodoo:

  1. Resize the window to the size of the table,
  2. Move the window to the lower right corner,
  3. Double-click on the table,
  4. Then press a few arrow keys.

Try your best and if you are still unsuccessful after a few tries, or are unable to devise a consistent mechanism, please let us know.

By default, the script displays all cell information (including the data, the cell's headers, and the cell's position) automatically. The following keys will change this output:

Travel Expense Report
Meals Hotels Transport subtotals
San Jose
25-Aug-97 37.74 112.00 45.00
26-Aug-97 27.28 112.00 45.00
subtotals 65.02 224.00 90.00 379.02
Seattle
27-Aug-97 96.25 109.00 36.00
28-Aug-97 35.00 109.00 36.00
subtotals 131.25 218.00 72.00 421.25
Totals 196.27 442.00 162.00 800.27

Figure 6: Travel Expense Report Sample Table [D]