A scenario for splitting ATAG into two documents

On the last call, I took an action item to set out a scenario for how ATAG 
might be split into two documents, one concentrating on guidelines related to 
content creation and the other on guidelines related to authoring interfaces.

In my opinion, such a split would give us some much needed flexibility with 
respect to accomodating the various software accessibility guidelines, 
standards and legislated rules while at the same time simplifying the complex 
ATAG conformance scheme. I don't believe that the "back of the bus" argument 
holds water because it appears to me that it is actually easier to create an 
accessible authoring interface (especially very simple ones such as text 
editors) than to add in the all the checking, repairing and prompting that is 
required by the accessible content part of ATAG. Therefore, tools may actually 
begin by seeking to meet the authoring interface document.

The scenario follows:

Document 1: Authoring Tool Accessibility Guidelines: Output

Purpose: Authoring tools should enable and support the production of accessible 
content and promote and integrate accessibility solutions so that the output 
from these tools will be more accessible [defined as conforming to WCAG 
(developer choice for WCAG version)].

Conformance Scheme:
• Uses the same three-level system as ATAG2.0 final call draft except that it 
would be simpler since there would be only one type of relative priority 
checkpoint instead of three.

Proposed changes to ATAG final call draft under this scenario: 
• Sect 1.3 simplified (though we should keep “Everyone should have the ability 
to create and access Web content” and have a link to the new Authoring 
Interface document)
• Sect 1.4 (Relationship with other guidelines and standards) is simplified
• Sect 1.4.2 (Relationship to ISO16071) is removed
• Sect 1.5 (How this document is organized) is simplified
• Guideline 1 removed (moved to Authoring Interface document)
• Glossary (sect 4) is simplified

Authoring Tool Accessibility Guidelines: Authoring Interfaces

Purpose: Authoring tools must have an authoring interface that is accessible 
[defined as:
• (1) meeting a series of interface requirements specific to authoring,
• (2) conforming to UAAG for any user agent interface functionality,
• (3) conforming to WCAG for interface components that are implemented as Web 
content (the developer has choice of WCAG version), and 
• (4) meeting the requirements of at least one published guideline (e.g. IBM 
Java Accessibility Guideline), specification (e.g. ISO16071) or legislative 
(e.g. Section 508, etc.) document (developer choice) with special attention to 
interface components that are not covered by (1), (2) or (3), above]

Conformance Scheme:
• We might actually want to consider a simpler scheme for this document with a 
single minimal level of conformance.

Some proposed content for this document under this scenario: 
• Checkpoints previously in Guideline 1 of ATAG final draft (except 1.1 which 
his now handled by parts (2), (3), (4), above.
• Information on how to interpret UAAG through an authoring interface lens. 
• Information on how to interpret WCAG through an authoring interface lens.
• Information on what it means for a guideline, specification or legislative 
document to be published. Emphasis to be placed on the reasonableness of the 
choice. Developers would have to state their choice publicly so choosing 
extremely lenient standards would potentially cause negative publicity.

--

Questions? Comments?

Cheers,
Jan

-- 
Jan Richards, User Interface Design Specialist 
Adaptive Technology Resource Centre (ATRC), University of Toronto 

  Email: jan.richards@utoronto.ca 
  Web:   http://jan.atrc.utoronto.ca
  Phone: 416-946-7060 
  Fax:   416-971-2896

Received on Friday, 18 February 2005 17:26:50 UTC