2002 Conference Proceedings

Go to previous article 
Go to next article 
Return to 2002 Table of Contents


HOW ASSISTIVE SOFTWARE SUPPORTS WEB ACCESSIBILITY

Jean-Marie D'Amour, M.Ed.
Instructor
CAMO for persons with disabilities

Catherine Roy
Advisor, Training and Employment Development
CAMO for persons with disabilities

1. PERTINENCE

The World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI) has published the Web Content Accessibility Guidelines 1.0 and the Techniques for Web Content Accessibility Guidelines 1.0. There are 14 guidelines and 65 check points. These check points refer to 85 different techniques. All of these elements comprise what is asked of Web developers.

However, screen reader software doesn't always provide access to information required from Web developers to ensure content accessibility. For example, complex images, like diagrams and graphics, must have a long description via the "longdesc" attribute. And yet, none of the present screen readers support this option. Only IBM Home Page Reader, a voice browser, gives access to this particular information. As a result, Web authors are asked to use the "longdesc" attribute and to add a d-link as an alternate solution.

Among Web accessibility experts and Web developers trying to make their sites accessible, numerous questions have been raised concerning the way various assistive software treat or simply ignore the accessibility information added to pages. Not surprisingly, developers are rather unmotivated to bring modifications that will hardly be, if at all, considered by the assistive software. And when the accessibility information is treated, they would like to understand how it will actually be rendered to users in order to adjust their methods to attain the desired results.

Unfortunately, the aforementioned example isn't an isolated case. That is why we felt it necessary to conduct this comparative study on various screen readers and text to voice browsers in order to verify to what extent these tools support Web accessibility recommended by the WAI as well as to explain how the accessibility information is treated or not and how it is transmitted to users.

Our study answers such questions and could become a useful reference tool to those concerned with Web accessibility. Additionally, our evaluation proposes recommendations for screen reader software developers that would allow them to improve support to Web accessibility. To attain this goal, there is effectively a need for Web and assistive technology developers to work together.

2. METHODOLOGY

In the first stage of our study, we made a comparison between the JAWS 4.0 screen reader from Freedom Scientific and the IBM Home Page Reader voice browser. Our presentation for CSUN will also include:

* Window Eyes from GW Micro;
* Outspoken from Alva Access Group;
* Hal from Dolphin Computer Access;
* Windows bridge from Syntha-voice Computers.

Additionally, we will present results for the 3 previous versions of JAWS since this product is very widely used and many users continue to work with old versions they can't afford to update.

Among the 85 techniques recommended by the WAI, we have retained 33 elements of information required to ensure a Web page's accessibility and transmitted or not through assistive technologies. These elements are sorted into 6 categories, the complete list of which is annexed to the final paper:

* Structure elements and user control;
* Text equivalents;
* Keyboard access;
* Form information and navigation;
* Table information and navigation;
* Frames information and navigation.

3. RESULTS

The comparison between JAWS 4.0 and Home Page Reader 3.0 reveals that JAWS supports, entirely or partially, 52% of the elements of information (n-17) while HPR supports 70% (n-23). The results follow:

Category JAWS 4.0 IBM HPR 3.0 N element
Structure elements and user control 13% 63% 8
Text equivalents 86% 64% 7
Keyboard access 0% 0% 2
Form information and navigation 67% 100% 6
Table information and navigation 63% 100% 8
Frames information and navigation 50% 25% 2
TOTAL 52% 70% 33

4. DISCUSSION

We will now briefly discuss each category.

4.1. Structure elements and user control

Structure elements include headings (H1-H6), lists and nested lists which are all elements of information essential to comprehending and getting one's bearings in a document. Notably, headings allow a user who can only access a sequential reading of the text to explore a document, thus compensating for the inability to get an overall view visually.

JAWS 4.0 offers no information about these elements;

HPR, on the other hand, indicates these elements via an auditory signal or a configurable leading and trailing text. HPR also allows one to navigate by headings and has a contextual locating feature that not only indicates the current element type and the position in the page, but always mentions the current section's heading to further facilitate navigation. Its only weakness is failing to indicate nested lists, which could also make navigation much easier.

Primary language and changes in language is important information for voice synthesiser users. Indeed, this type of assistive technology does not make reading in another language easy without changing the language option. If not, the text is incomprehensible. Present voice synthesisers offer different languages that the user can alternate between.

JAWS users must make the language changes manually;

HPR, on the contrary, locates language attributes in the document and changes the synthesiser engine on the fly.

Popup windows are annoying for many users, which doesn't prevent site developers from using them and sometimes abusing them. They are even more disorienting for people who can't see them suddenly appear and who then find themselves in a new window without knowing. The WAI recommends users be warned that a current link will open a new window.

JAWS says "New browser window" each time a popup window appears;

HPR plays a little jingle every time it opens a new window.

4.2. Text equivalents

The alt text is a way of providing textual information about visual elements. This information is essential for blind users who cannot access the content otherwise. The HTML 4.01 Specification also provides for the possible use of the title attribute defined as "advisory information about the element for which it is set."

JAWS confuses these attributes and always privileges the title attribute when both are present. JAWS applies this logic to textual links as well. And yet, a title is complementary information while alt text is an essential way of offering a textual equivalent to visual content;

HPR reads the alt text but not the title. The ideal solution is to have access to both the alt text as the default and the title as a complement with the contextual information command;

JAWS et HPR treat NULL alt texts (ex. alt="") as images without alt texts. The function of the NULL alt text is to eliminate all reference to an image because it is purely decorative and deemed unimportant. JAWS and HPR should add a category before the "all images" category that could be called "all images with no alt text";

Finally, let us note that HPR alone supports the longdesc attribute, the purpose of which is to provide a link to a descriptive page for complex visual elements.

4.3. Keyboard access

HTML 4.01 allows developers to define tabulation order in a document, which can be crucial with certain types of dynamic menus or javascript effects that take the keyboard into consideration, as recommended by the WAI.

Unfortunately, neither JAWS nor HPR take this information into account. JAWS does however allow the user to deactivate the virtual PC cursor in order to return to Internet Explorer's basic settings. The problem is that the user can't seriously be expected to guess when would be the appropriate time to do so.

4.4. Form information and navigation

Forms are crucial elements for all search and e-commerce operations.

JAWS treats forms in the same manner it does Windows dialog boxes. However, it does not consider the arrangement of elements with FIELDSET, nor does it read LEGENDS which contain precious information for a user filling out a form;

HPR supports all form elements. It could however adopt an interface resembling that of Windows dialog boxes (ex.: alt+down arrow for combobox).

4.5. Table information and navigation

A data table is a very complex environment for non-visual users. A sighted user can, with a quick glance, understand in what way the information is organised. A blind user however relies on information such as a summary to get a general idea of the table. Identifying header cells and their relation to data cells is essential for navigation and comprehension of content.

JAWS generally does a good job of supporting the user in this environment but does not use heading abbreviations, has a few weaknesses in regard to cell association and has major problems with empty cells;

HPR does an excellent job except for the axis attribute, which is a minor problem.

4.6. Frames information and navigation

Frames are not as popular as they used to be but are still used on many sites. The WAI recommends that a title be given to each frame that is significant to its function and to provide a longdesc attribute to explain the interaction between frames if their titles are not sufficiently explicit.

JAWS reads the frame titles but does not give access to the longdesc;

HPR reads the title of the document uploaded in the frame and does not give access to the longdesc. Additionally, HPR treats each frame separately and doesn't offer a global way of exploring or searching a page.

5. CONCLUSION

Web accessibility is an issue that must mobilise both content and assistive technology developers. If both do their part, the Web will be a much better place for everyone.

This evaluation illustrates a very significant difference, on both quantitative and qualitative levels, in favour of HPR in regards to the treatment and transmission of accessibility information integrated into Web pages.

A few minor improvements to the user interface would make HPR even more user-friendly.

As for JAWS, it could draw inspiration from its competitor and improve the various aspects mentioned in this study.


Go to previous article 
Go to next article 
Return to 2002 Table of Contents 
Return to Table of Proceedings


Reprinted with author(s) permission. Author(s) retain copyright.