Adaptive Technology Resource Centre, University of Toronto
http://idrc.ocad.ca
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 accessibilityguidelines, the Web, unlike many traditional environments, is accessible to users with disabilities. Thegreatest access challenge, relative to the Web, is therefore to make sure that all authors followaccessibility 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 arepublished and available on the Web. Tools exist that allow the author to check the accessibility of theirsite. Legislation is in place mandating accessible web sites. However, all of these mechanisms require thatthe author know about accessibility guidelines, have the will to follow them, know where to get thenecessary instructions and know how to technically implement them.
A more successful method of meeting this challenge may be in providing supports and information in theWeb authoring tool. The majority of authors use Web authoring tools and the percentage who preferauthoring tools to manual HTML markup is increasing. The authoring tool is a mechanism that can reachauthors who have neither the knowledge or even the will to make their Web pages accessible. This paperwill address a number of projects and initiatives with the common goal of creating Web authoring toolsthat support the creation of accessible web pages. These include:
- HoTMetaL 4.0
- WAI Authoring Tool Guideline Working Group
- ATRC Authoring Tool Evaluation Project
- The A-Prompt Project
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 upa world of information for users with visual disabilities who could access the textualcontent quickly using text browsers such as Lynx in combination with their alternativescreen access system. However, graphical browsers such as Mosaic and Netscaperevolutionized the Web by introducing a graphical point and click interface along with avariety 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 textbased operating systems previously enjoyed.
Mitigation of Accessibility Losses
Many groups have posted guideline documents in order to mitigate these accessibility losses. The present leader in establishing accessibility guidelines for page authoring is been the Web Accessibility Iniative (WAI), a sub-committee of the World Wide Web Consortium (W3C). The mandate of this group is to promote a high degree of usability for people with disabilities. To this end, the WAI is coordinating many organizations that have produced Web accessibility reference documents in the past, in order to develop a comprehensive and unified set of accessibility guidelines. The most recent draft categorizes, by priority, elements and formats to avoid and recommends possible redundancies or alternatives, in an attempt to restore some of the landmarks in the new graphical desert. However, despite a great deal of work, a large scale author response has not been forthcoming.
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 ofcomputers to do the boring, repetitive and guideline intensive work instead of askingpeople to scrutinize and change their own authoring habits. With theproliferation of GUI word processor style HTML editors, a unique opportunity for includingaccessibility 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 asaccessibility is concerned, but the first steps have been taken. For the purposes of thispaper, the specific features of this product are not as important as the design prioritiesthat emerged as the most essential characteristics that a successful access-aware HTMLauthoring 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:
- the vast majority of users have never had exposure to accessibility issues and will not seek out ways to enhance accessibility on their own.
- many authoring tool users are attracted by the time saving site building wizards and GUI word processor interfaces that allow sites to be constructed with limited HTML knowledge.
- accessibility is a stylistic quality of a page or site, not just an extra that can be included as an afterthought.
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:
- Site building utilities that automatically include ALT text and avoid access hazards
- ALT text association files (that save a record of ALT text used for a particular image, to be used as a default entry)
- D-text file creation support (implemented in HoTMetaL 4.0)
- Automatic Text-Only, NOSCRIPT and NOFRAMES generation
- A function to spot problematic colour combinations
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:
- Review of existing recommendations and guidelines for web authoring to determine which guidelines can be supported within theauthoring tool and recommended mechanisms for doing so.
- Creation of guidelines for developing authoring tools which support the creation ofaccessible documents. These will include priority levelsand example implementations.
- Authoring of example help files which can be included in authoringtool help files to instruct authors on the need and mechanisms for creatingaccessible Web documents
- Prototyping and specification of tools for partially automating such processes as linking d-links,reusing alt-text, creating accessible style sheets, etc.
- Assessing the Current Market - ATRC Authoring Tool Evaluation ProjectTo 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:
- an HTML checker
- an Attribute dialog modifier
- Accessibility utilities, and
- an Accessibility user interface model.
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 havebeen ineffective in increasing the actual use of accessible HTML authoring practices onthe Web. In order to change this state of affairs, the accessible HTML community must winthe cooperation of the most popular Web authoring product makers to ensure that theirproducts include informative, easy-to-use and effective authoring support.