This document is hosted on the Trace R&D Center Web site. Please visit our home page for the latest information about Designing a More Usable World - for All.
Wendy Chisholm
Mark Novak
info@trace.wisc.edu
The W3C WAI Page Authoring Guidelines (Vanderheiden, et al, 1998a) contains
nineteen general concepts that Web page authors should follow to make their
pages more accessible and usable, not only to people with disabilities, but
for newer page viewing technologies (mobile and voice), for electronic agents
such as indexing robots, and etc. In an accompanying document, Techniques for
"W3C WAI Page Authoring" (Vanderheiden, et al, 1998b), each of the
Page Authoring Guidelines are further explained, with one or more techniques
that may be used to satisfy the guideline.
In this paper/presentation, we will talk about and demonstrate how scripts and style sheets can be implemented today, and still work on systems that do not support scripts and style sheets ("Transform gracefully"). We also talk about and demonstrate how the data in a table can be presented and navigated both via scripting and by an accompanying application ("Context and navigation").
The W3C WAI Page Authoring Guidelines demonstrate that there are three basic concepts to create accessible Web sites:
The document stresses that "Accessibility does not mean minimal page design, it means thoughtful page design (Vanderheiden, et al, 1998a)." Therefore, newer technologies such as scripts and style sheets should not be avoided, but designed and used with care. In this paper/presentation, we will show how scripts and style sheets can be used to increase the accessibility of a page. We will also show how marking up a table according to the HTML 4.0 specification will allow other programs and eventually browsers, to restructure the data in a table to allow a user to understand and navigate the table via speech, the keyboard, etc.
Note. We use many acronyms in this paper. Fear not, they are defined at the end.
In the WAI Page Authoring Guidelines, under the first category "A. Make sure pages transform gracefully across users, techniques, and situations," the ninth guideline states: "
A.9 Ensure that pages using newer W3C features (technologies) will transform gracefully into an accessible form if the feature is not supported or is turned off.
Some more recent features that are not completely backwards compatible include frames, scripts, style sheets, and applets. Each release of HTML has included new language features. For example, HTML 4.0 added the ability to attach style sheets to a page and to embed scripts and applets into a page. Older browsers ignore new features and some users configure their browser not to make use of new features. These users often see nothing more than a blank page or an unusable page when new features do not transform gracefully. For example, if you specify an image as the source of a frame (via the "src" attribute), then there is no simple way to attach alt-text (see A.1) to that image.
As is more often the case, people are finding ways to use scripts to create animated text effects. One such example was created on the WebReview site as a demonstration of how to create dynamic HTML (WebReview, 1998). In its original state, the page did not transform as gracefully as it could - making it confusing when read without style sheets. After changing the order of how the document was structured, the page transforms very gracefully. (i.e., it is readable). This assumes that a user can turn scripts off or that a browser does not support scripts.
Screen readers have many problems with tables. As of today, only one screen reader (that we know of) can take the multiple columns of a table and display them in one column This works fine if a table only contains a few columns of text, like a newspaper. Other screen readers typically read an entire row as one sentence, thus running information from cells together into one intelligible phrase. This becomes even more confusing when it is a table of numbers (a bus schedule for example). For this type of table, it is necessary for a user to be able to navigate the table by cell. Current browsers and screen readers do not typically have the ability to use the keyboard to navigate within the table. Even if a user can configure a screen reader to read a data cell at a time, they probably cannot get the corresponding row and column header information associated with a particular data cell. They also may not be aware of when they have navigated into or out of a data table.
To help solve these issues, the WAI Page Authoring Guidelines (Vanderheiden, et al, 1998a), under the second category "B. Provide context and orientation information for complex pages or elements," the third guideline states:
B.3 Ensure that tables (not used for layout) have necessary markup to be properly restructured or presented by accessible browsers and other user agents.
Many user agents restructure tables to present them. Without appropriate markup, the tables will not make sense when restructured. Tables also present special problems to users of screen readers. These guidelines benefit users that are accessing the table through auditory means (e.g., an Automobile PC which operates by speech input and output) or viewing only a portion of the page at a time (e.g., users with blindness or low vision using speech or a braille display, or other users of devices with small displays, etc.).
Techniques:
- Provide summaries for tables (via the "summary" attribute on TABLE). [Priority 3]
- Identify headers for rows and columns (TD and TH). [Priority 2]
- Where tables have structural divisions beyond those implicit in the rows and columns, use appropriate markup to identify those divisions (THEAD, TFOOT, TBODY, COLGROUP, the "axis" and "scope" attributes, etc.). [Priority 2]
- .Provide abbreviations for header labels (via the "abbr" attribute on TH). [Priority 3]
The following current interim technique is discussed in guideline A.12. ("Use interim accessibility solutions so that assistive technologies and older browsers will operate correctly."):
5.Until user agents and screen readers are able to handle text presented side-by-side, all tables that lay out text in parallel, word-wrapped columns require a linear text alternative (on the current page or some other). [Priority 2]
We looked at solving "the table problem" using a client side JavaScript. Our approach was to:
To associate row/column header information with each data cell, we used an approach recommended in the HTML 4.0 specification (Raggett, et al, 1998). Essentially the steps in pseudo code would be as follows:
Note, even though additional Table information is sometimes available in the HTML 4.0 standard (e.g., headers attribute, axis attribute, etc.), this information was collected but not used for our experimental scripts.
Our next approach was to use the extended object model exposed by IE 4, and access a Web page using a combination of C++ and COM via an executable program.
Advantages to this approach:
Since the introduction of IE 3, Microsoft has supported a component architecture that allows increasing levels of access and control over their browser from an external application. Using COM, an external application can attach to IE and perform a variety of tasks, such as limiting the internet addresses one can access, or provide an audio indication when a page has completed loaded. Using COM also allows an external application to access the DOM and the event model of IE, and therefore access and possibly control all the elements of a Web page.
Our approach was to develop an application that would again look to address the problems encountered by individuals with a visual disability when they try to navigate and understand data tables on a Web page. The application developed used the same structure as tried when experimenting with tables using JavaScript. In addition, we were also able to collect header and anchor/link information.
This document is hosted on the Trace R&D Center Web site. Please visit our home page for the latest information about Designing a More Usable World - for All.