1999 Conference Proceedings

Go to previous article 
Go to next article 
Return to 1999 Conference Table of Contents


Authoring Tool Support: "The Best Place to Improve the Web"

Laurie Harrison
Jan Richards
Jutta Treviranus
Adaptive Technology Resource Centre, University of Toronto
http://www.utoronto.ca/atrc

Introduction

The World Wide Web is quickly becoming a new form of library, news media, trade show, storefront, town hall, classroom, and community centre. If authors who create Web pages follow accessibility guidelines, the Web, unlike many traditional environments, is accessible to users with disabilities. The greatest access challenge, relative to the Web, is therefore to make sure that all authors follow accessibility guidelines. When we talk about all authors, this encompasses professional design firms, government webmasters, mom and pop retailers, and the kid down the block. The guidelines are published and available on the Web. Tools exist that allow the author to check the accessibility of their site. Legislation is in place mandating accessible web sites. However, all of these mechanisms require that the author know about accessibility guidelines, have the will to follow them, know where to get the necessary instructions and know how to technically implement them. A more successful method of meeting this challenge may be in providing supports and information in the Web authoring tool. The majority of authors use Web authoring tools and the percentage who prefer authoring tools to manual HTML markup is increasing. The authoring tool is a mechanism that can reach authors who have neither the knowledge or even the will to make their Web pages accessible. This paper will address a number of projects and initiatives with the common goal of creating Web authoring tools that support the creation of accessible web pages. These include:

Background

While in recent years the issue of the accessibility of HTML to users with visual disabilities and other constraints has become a topic of great concern, it was not always this way. HTML began as a simple and predominantly text based subset of the more complicated SGML. It opened up a world of information for users with visual disabilities who could access the textual content quickly using text browsers such as Lynx in combination with their alternative screen access system. However, graphical browsers such as Mosaic and Netscape revolutionized the Web by introducing a graphical point and click interface along with a variety of new official and unofficial HTML additions. Innovative designers have misused the structured assumptions of HTML for their own aesthetic purposes and introduced new dynamic elements such as Java applets and active-X controls. The result has been an erosion of the accessibility that users with disabilities, slower connections and text based operating systems previously enjoyed.

Mitigation of Accessibility Losses

The Challenges

There appear to be two key factors in the current prolific production of inaccessible Web pages. The first is ignorance, or more specifically, the possibility of authoring Web pages with little or no understanding of HTML. The extent of HTML illiteracy on the Web is underscored by the general move towards WYSIWYG authoring tools that advertise themselves as usable without knowledge of HTML. In addition, even those who are skilled in HTML are often ignorant of Web accessibility guidelines.

A second problem is laziness, or, in any case, the lack of motivation to do repetitive, complicated or time consuming activities that may be viewed as unimportant. Reworking HTML code or adding redundancies to accommodate computer users with disabilities is often pushed aside in the rush to get information out on the Web as quickly as possible. The extra step of ensuring accessibility is generally not an attractive undertaking for the web designer.

The key to increasing the accessibility of the Web is to take advantage of the power of computers to do the boring, repetitive and guideline intensive work instead of asking people to scrutinize and change their own authoring habits. With the proliferation of GUI word processor style HTML editors, a unique opportunity for including accessibility automation presents itself.

Lessons Learned from HoTMetaL 4.0

The first commercial, access-aware HTML authoring tool was HoTMetaL 4.0 from SoftQuad, created in consultation with the Adaptive Technology Resource Centre (ATRC), University of Toronto. The released product is still a work in progress as far as accessibility is concerned, but the first steps have been taken. For the purposes of this paper, the specific features of this product are not as important as the design priorities that emerged as the most essential characteristics that a successful access-aware HTML authoring tool must possess. These characteristics are the 3 "tions": information, automation and integration.

Information

This is the most important of the "tions", since it is necessary to overcome author ignorance on the subject of accessibility. The methods by which accessibility information should be presented are constrained by three important factors: Clearly, the best way to accommodate these constraints is to make the provision of accessibility information an active part of the authoring process. Instead of simply including accessibility information within a program’s help files; guidelines and accessibility fixes should be presented as the user initiates inaccessible authoring practices. In this way, the presented information can be made succinct and context sensitive, educating the author as the work progresses; instead of overwhelming the author with problems when a check is made on a completed page. These brief initial warnings should include links to the help system for more information and (when possible) automated tools to perform or support corrective measures. Additional information or links to information should also be added to other major areas of authoring tools, such as: site management tools, specialized utilities and content wizards.

Automation

The second characteristic of an accessibility-aware HTML authoring tool is a high degree of automation; needed to overcome author laziness. Just as FrontPage 98 includes a wide array of utilities including ones that maintain button bars and modifies links, the access-aware HTML authoring tool should include tools that make repetitive and stylistic tasks into one-time, well-guided occurrences. Other automation ideas include:

By automating the repetitive and tiresome aspects of authoring accessibly, an author’s attention can be focused on description writing, where the human ability to understand the content of an image, sound or animation is imperative.

Integration

Finally, any accessibility tools that are added to an HTML authoring product must be integrated seamlessly into the look, feel and function of the product. If this requirement is not met, then the tools may assume the appearance of tacked on, second class features. This in turn will lead users to the belief that the authoring support tools have been added for reasons besides their necessity to page design. In addition, if the authoring support tools make use of user interaction styles that differ from the host product, some users may be hesitant to learn how to use them. The end result of inconsistent look, feel or function may be an unwillingness or inability of authors to make use of the accessibility features even when they are present.

Setting New Goals - Authoring Tools Guidelines Working Group

In order to introduce this threefold approach to accessibility to the software developers who are producing HTML authoring tools, a new Authoring Tools Guidelines Working Group has been established by the WAI. While attention is being given to the need for accessible interfaces to accommodate Web page authors with disabilities, the current focus of the group is the creation of guidelines, documents and prototype utilities for authoring tools which provide author support for creating accessible documents. Their tasks include:

Ongoing work will involve provision of information and guidance to the WAI Education group related to educating, negotiating with and lobbying authoring tool developers to adopt recommendations.

Assessing the Current Market - ATRC Authoring Tool Evaluation Project

To demonstrate the strengths and deficiencies of current page authoring tools, the ATRC is undertaking a review of popular authoring tools currently available on the market. A measurement tool is being developed, using the WAI guidelines as a benchmark criteria for accessible page authoring. In addition, the principles of information, automation, and integration will also be considered. The scoring system be weighted according to the priority levels assigned to each of the accessiblity criteria in the WAI guidelines, with consideration being given to the three principles outlined above, as applicable.

During Phase 1 of this research project, between five and ten HTML authoring tools will be reviewed and scored using the measurement tool. It is hoped that this product review, conducted by an established centre of excellence in the field of accessibility, will highlight the need for incorporation of tools, utilities and help file resources into HTML authoring software. Phase 2 of the project will include adaptation of the measurement tool to allow evaluation of HTML conversion utilities, and also evaluation of courseware development tools used for creating Web-based distance education programs. It is anticipated that results of Phase 1 and preliminary results for Phase 2 will be available at the time of presentation of this paper.

The A-Prompt Project - A New Model for Interface Design

The ATRC, in collaboration with the Trace Centre, University of Wisconsin, is currently developing a software module that can be integrated into HTML authoring tools to support authors of Web pages in creating HTML documents which are accessible. Building on the lessons learned in the SoftQuad project, the goal is to develop a modular tool that supports accessible Web page authoring.

The software module will be in the form of a Windows DLL (Dynamic Linked Library), called the Acccessibility Validation DLL (AVDLL), which can easily be integrated into exisitng HTML authoring tools. The AVDLL will also be ported to an Accessibility Validation Java Bean (AVJB).

The module will have four components:

The Windows DLL and Java Bean will be created for developers of HTML editors for all popular platforms, and created in such a way that it can be easily integrated into HTML authoring tools applications with minimal effort or change to code.

Summary

In closing, it seems clear that published guidelines and pleas for cooperation have been ineffective in increasing the actual use of accessible HTML authoring practices on the Web. In order to change this state of affairs, the accessible HTML community must win the cooperation of the most popular Web authoring product makers to ensure that their products include informative, easy-to-use and effective authoring support.


Go to previous article 
Go to next article 
Return to 1999 Conference Table of Contents 
Return to Table of Proceedings


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