SAP DESIGN GUILD

Authoring Tools Accessibility Guidelines, Take 2

By Jan Richards, Editor, ATAG 1.0 & Wombat ATRC, University of Toronto – 02/18/2002

 

Q: What does a new guidelines document intended for Web authoring tool developers have in common with a burrowing marsupial native to Australia?
A: The same name.

The W3C Authoring Tools Accessibility Guidelines Working Group (ATAG-WG) is developing a new version of the Authoring Tools Accessibility Guidelines (ATAG) to replace version 1.0, which has been a W3C recommendation since February, 2000. The codename given to the new working draft is Wombat.

Important Note: The ATAG document (Wombat) is still a working draft. Any part of it is subject to change without notice. Therefore, developers should continue to refer to ATAG 1.0 for formal conformance.

 

What is the Authoring Tools Accessibility Guidelines (ATAG)?

Answering this question requires some history.

For years, people with various disabilities had been having trouble accessing certain kinds of content, such as images, tables and forms, on the Web. As a result, the Web recommendations body, the W3C, formed the Web Accessibility Initiative (WAI) to develop recommendations, which might alleviate these problems. The WAI, in turn, formed three working groups to examine the following areas: Web Content, Authoring Tools, and User Agents (browsers).

The Web Content Accessibility Guidelines Working Group (WCAG-WG) was given the question, "what is accessible Web content?" Its answer came in May, 1999 when the Web Content Accessibility Guidelines (WCAG) version 1.0 was released as a recommendation. It is a comprehensive document that contains sixty-five checkpoints that deal with issues from proper markup usage to Web page organization.

Similarly, the Authoring Tools Accessibility Guidelines Working Group (ATAG-WG) was given two questions. The first, "how can authoring tools be designed to produce this accessible Web content?", was related to that given the WCAG-WG. The second, "how can authoring tools be made accessible to authors with disabilities?" addressed the accessibility of the tools, themselves.

The group's first answer, ATAG 1.0, was released in February 2000. The general guideline headings of this document are:

  1. Support accessible authoring practices.
  2. Generate standard markup.
  3. Support the creation of accessible content.
  4. Provide ways of checking and correcting inaccessible content.
  5. Integrate accessibility solutions into the overall "look and feel".
  6. Promote accessibility in help and documentation.
  7. Ensure that the authoring tool is accessible to authors with disabilities.

The approach that the working group took to creating these guidelines made the following assumptions:

  1. An "authoring tool" is any software that is used to produce content for publishing on the Web, whether it is a markup/style-sheet/programming editor, a word processor saving as markup, a multimedia editor, or a site management tool.
  2. 2. WCAG will be considered to be the definition of "accessible Web content", with the understanding that this definition may change as new versions of that document are released.
  3. 3. Most authors do not know about accessibility. And, even if they did, they would not wish to read WCAG any more than they want to read the HTML specification.
  4. 4. Authoring tools are in the business of helping people create their content, not nagging them until they change to a different tool.

Following the first assumption, the ATAG-WG has created guidelines (and accompanying checkpoints) that are largely content independent. They apply more or less equally to any tools that create Web content, regardless of whether it is a markup editor, programming tool or multimedia application. For example, a typical checkpoint might be, "Document all features that promote the production of accessible content".

Following the second assumption, the guidelines refer to WCAG for specific requirements related to accessible content. So, instead of describing every accessibility problem to be avoided during automated content generation and then describing them all again for checking, ATAG simply points to WCAG to define what "accessibility problems" means. In order to fully conform to such relative ATAG checkpoints, developers need to implement solutions for all sixty-five WCAG checkpoints. However, partial conformance levels on the basis of the priority numbers given by WCAG (i.e. only priority 1's for Level A, etc.) are also available. This means that ATAG is a relatively short document (twenty-nine checkpoints) that unpacks into a large number of requirements (22 stand alone requirements + 7 relative to WCAG requirements * 65 WCAG checkpoints = 477 total), however, once the functionality to check for a WCAG checkpoint is implemented, it is often possible to re-task it to meet other ATAG requirements that point to WCAG, significantly reducing the effort required for conformance.

Following the third assumption, the ATAG guidelines have a definite slant towards tight integration of accessibility-related functionality into the tool and automation of accessibility-related tasks for the user. This is an attempt to encourage the development of authoring systems that do not require extensive user knowledge about the details of WCAG in order for them to produce documents that conform to it.

The final assumption is a realization, by the working group, that the best way to turn people against an idea is to bombard them with information and warnings that interrupt their preferred pattern of work. ATAG is not an attempt to tell developers how their authoring tools should look or feel. Rather, the working group has only defined what kinds of functionality are conducive to the production of accessible content as an end product of the authoring process. It is up to individual developers to determine how this functionality is best implemented in their tools, for their users. If developers need more guidance in this regard, the ATAG-WG has also published a techniques document that provides more concrete suggestions for implementations at the level of tool types.

 

What has Changed in Wombat (New Working Draft)?

The majority of the updates (so far) involve minor edits and rewordings. The two primary exceptions are situations in which ATAG 1.0 checkpoints are combined or subsumed under others as techniques and changes to the checkpoint structure to facilitate conformance testing.

The following ATAG 1.0 checkpoints are combined in Wombat:

The following ATAG 1.0 checkpoints are subsumed as techniques of other checkpoints in Wombat:

The only new checkpoint in Wombat is one that requires functionality related to accessibility checking, creating structured content and prompting for alternative equivalents always be clearly available to the user.

The second major change to ATAG 1.0 in Wombat has been the of new document features to aid conformance testing. In the new document, each checkpoint includes (or will include) a "rationale" that briefly explains why the checkpoint is required (helping implementers to understand the intended spirit of the requirements), a "required basic functionality" section that spells out what needs to be implemented for bare conformance, and a "more advanced solutions" section that highlights a particular implementation technique that goes beyond what is strictly required.

Finally, some vocabulary changes were made. A new definition of "prompt" was incorporated to emphasize the fact that tools that do not interrupt the workflow of the user, can achieve ATAG conformance. This was implicit in ATAG 1.0, but it was still a common concern raised by developers. Other vocabulary changes include a glossary that has, in large part, been drawn from the "combined WAI glossary" as part of an effort to unify terms used across multiple WAI guideline working groups.

 

What has Stayed the Same?

For developers who might be worried about the development of a new version of guidelines they are already in the process of implementing, the great continuity between ATAG 1.0 and Wombat should be reassuring. Some the checkpoints may be reorganized and clarified, but the general guidelines and the requirements as a whole, have been almost totally preserved. In addition, Wombat retains the same structure: guidelines that set forth a principle, checkpoints that allow compliance to be judged, and links to helpful implementation techniques in an external note. Finally, it is expected that Wombat will maintain the same priority and conformance scheme that is used in ATAG 1.0.

 

Why is the New Document Called Wombat?

That has to do with version numbering and the fact that W3C recommendations must only reference stable documents. As previously stated, the ATAG document frequently points to WCAG as the standard for accessible Web content. Because of this dependency, the working group has decided that any future versions of ATAG must have the same major version numbers as the WCAG recommendations that they reference. Ideally, the working group wants to release Wombat as ATAG version 2.0 as soon after the release of WCAG 2.0 as possible. This would ensure that the ATAG checkpoints point to stable checkpoints in the WCAG 2.0 recommendation.

However, WCAG 2.0 is a complex undertaking, and, for whatever reason, it may not have been released by the time Wombat is ready for release. In this case, the ATAG-WG may choose to release Wombat as ATAG 1.1, referring to the stable checkpoints in WCAG 1.0 and the definition of "accessible Web content" that they entail. Then, once WCAG 2.0, is released, an ATAG version 2.0 can be released that is essentially the version 1.1 text, with links that point to the new WCAG recommendation.

In other words, the ATAG working group is hedging their bets, so that they can release the new version as either 2.0 or 1.1, depending on the progress of WCAG 2.0 towards recommendation status.

 

But, why is it Called Wombat?

No reason. Really.

 

For more information, see:
The ATAG-WG home page

 

Important Note: The ATAG document (Wombat) is still a working draft. Any part of it is subject to change without notice. Therefore, developers should continue to refer to ATAG 1.0 for formal conformance.

 

top top