Guidelines for accessible authoring tools

WAI is responsible for several sets of guidelines. The working draft 2.0 of the Authoring Tool Accessibility Guidelines (ATAG) has now been published and you are welcome to comment on this draft.

Story by: Morten Tollefsen - 28.05.2009

WCAG 2.0 (Accessible Web Content) was published on December 11th 2008. ATAG has now been updated to accommodate this. You can find more information at:

Call for Review: ATAG 2.0 Working Draft updated
W3C Public Working Draft of ATAG 2.0

ATAG aims to ensure that both the publishing tool and the content produced are accessible.

The main parts, principles, guidelines and success criteria

ATAG is built up in the same way as WCAG. The guidelines are however divided into two main parts:

• Accessibility of the authoring tool
• Production of accessible content

The main parts are based on principles, guidelines and success criteria.

Changes from the earlier draft

The following changes have been made to the earlier ATAG Draft:

• Guideline B.2.4 ("Assist authors with managing alternative content for non-text content.") is updated to more clearly explain how automated tools should treat alternative content.
• The introduction is adapted to WCAG 2.0. The list of examples of authoring tools is expanded and made clearer.
• Glossary definitions have been updated and clarified.
• Comments received on the 17 February 2009 Working Draft have been addressed.

What is an authoring tool

ATAG 2.0 defines an "authoring tool" as "any software application, part of an application, or collection of applications that interact with authors to create, modify or assemble Web content to be used by other people."
It is important to note that ATAG covers far more than traditional HTML editors.

Part A: Make the authoring tool user interface accessible

The principles for the guidelines in Part A are:

• Authoring tool user interfaces must follow applicable accessibility guidelines.
  (2 guidelines)
• Editing views must be perceivable.
  (3 guidelines)
• Editing views must be operable.
  (7 guidelines)
• Editing views must be understandable .
  (2 guidelines)

Refer to the standards for details regarding guidelines and success criteria.

Part B: Support the production of accessible content

The principles for the guidelines in Part B are:

• Production of accessible content must be enabled.
  (3 guidelines)
• Authors must be supported in the production of accessible content.
  (5 guidelines)
• Accessibility solutions must be promoted and integrated.
  (5 guidelines)

Refer to the standards for details regarding the guidelines and success criteria.

Feedback

WAI is requesting comments on the following :

• Is it clear how Guideline B.2.4 ("Assist authors with managing alternative content for non-text content.") would apply to website authoring tools? Is it clear how it would apply to content management systems or photo repository sites?
• Does the Glossary definition of "prominence" provide guidance for objective testing?
• Do the new examples of authoring tools in the Introduction sufficiently illustrate and differentiate between web and non-web functionality?
• Are there any areas in which the guidelines may be lacking?

My comments

Comments can be read at:
http://lists.w3.org/Archives/Public/public-atag2-comments/2009May/ 

I have submitted the following comments:

Too many links

This is really not a comment to the standard, but rather a comment about presentation.

The links in this type of document make the content harder to read: especially with a synthesized voice. Jaws and other screen readers show the links on separate lines. In addition, they announce something like "Link to the same page", eg:

A.2.2.1 Purpose of Added Presentation:
If an
"same page link" editing view modifies
"same page link" the presentation of
"same page link" Web content to provide
"same page link" authors with additional information (e.g., underlining misspelled words), then that additional information is made available via the platform.

It would be better if these link definitions could be switched on/off. The definitions could be opened in a separate window (for those who want it) if the links were removed.

Overlapping criteria

A.3.4.3 Navigate By heading: If an editing view displays a structured element set, authors can move the editing focus to the heading before or the heading after the item.
This is a good success criterion. As I read the standard, however, this is already covered by:

A.3.4.2 Navigate By Element type: If an editing view displays a structured element set, authors can move the editing focus forward / backward to the next instance of the same item.

Search

Guideline A.3.5 [For the authoring tool user interface] Provide text search.
I use text search a lot, both when I write my own content, and when I edit content created by others (I use a screen reader and screen reader users are search experts). This is an important guideline.

When I work with content written by others I often search for attributes: bold, underline, specific colors, font size, ... These properties are difficult to find when using a screen reader (particularly in content using several attributes). I suggest therefore that attribute / formatting-search should also be included in ATAG.

Reduce the number of success criteria

I think that success criteria that differ only with respect to WCAG level (A, AA, AAA) can be combined, for example:

B.3.1.1 Accessible Options Prominent (Level A)
B.3.1.2 Accessible Options Prominent (Level AA)
B.3.1.3 Accessible Options Prominent (Level AAA)

These success criteria are found both consecutively, and separated by other criteria.

News archive