Re: A scenario for splitting ATAG into two documents

I have serious concerns about this scenario re: W3C QA SpecGL.  How can there 
be a consistent and verifiable ATAG conformance model when an offerer can pick 
and choose to which of the many software accessibility requirements to claim 
conformance?  Each of the various software accessibility requirement sets may 
be quite different from one another.  I think that this scenario would seem to 
complicate ATAG conformance further..

I think that splitting ATAG into two documents is a major change which 
deserves serious consideration and input from the stakeholders and other 
relevant W3C activities.  At a minimum, I would want to take this scenario to 
the QAWG for consideration at the appropriate time, before proceeding any 
further..

I apologize in advance if I have misunderstood this scenario..

Thanks and best wishes,
Tim Boland NIST

Quoting Jan Richards <jan.richards@utoronto.ca>:

> 
> 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 Saturday, 19 February 2005 14:06:23 UTC