Re: A scenario for splitting ATAG into two documents

Hi Tim,

You are absolutely right that splitting the ATAG document is a major change 
that deserves serious consideration. It is not something that should be entered 
into lightly, especially at the "last call" phase of the W3C process. 

By the way: the issue of splitting the document is actually different from the 
issue of the conformance scheme that we choose for authoring interface 
accessibility - even though they are lumped together in the scenario below. One 
rationale for a document split is that the individual documents might be 
simpler and easier to understand than a compound document (resulting in earlier 
adoption). A rationale for a conformance scheme change for authoring interfaces 
is the comments put forward by the reviewers concerning the drawbacks of 
normatively referring to the ISO document.

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


Quoting boland@nist.gov:

> 
> 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 15:27:19 UTC