W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2005

Stucture of WCAG documents.doc

From: Gregg Vanderheiden <gv@trace.wisc.edu>
Date: Thu, 10 Mar 2005 11:33:23 -0600
To: <w3c-wai-gl@w3.org>
Message-Id: <20050310173326.02E6E1CC468@m14.spamarrest.com>
Some thought - trying to bring together what we have been discussing and
recent posts.

 

Pasted below and attached as a word doc.

 

Gregg

 


 


Structure of WCAG documents


 

This is much in agreement with Michael's write-up on the documents and the
roles.   The attempt here is to capture the roles of each of the documents
in a few concise words.


WCAG Document


Purpose


o       To specify what needs to be done in order to make Web content
accessible

o       This includes objectively measurable success criteria for doing so -
expressed in 3 levels

1.      Those things that MUST be done by the author and cannot be done by
AT that do not restrict the presentation of the content and that can be
applied to all types of content (except as noted as an exception)

2.      Additional things that can be done to make pages more accessible
that can be applied to all types of content including things that affect the
default presentation of the content.

3.      Additional things that can be done to make pages more accessible
including things that cannot be applied to all types of content or sites. 


WCAG Notes:


*    Success criteria are objective in that 8 or 9 of 10 informed people
would come to same conclusion regarding conformance of Web content to each
Success Criterion.


 Techniques Doc


Purpose


o       Provides information for each of the success criterion sufficient
for people not as expert in Web accessibility to be able to accurately
understand what is required by each Success criteria including what is
required when using each different type of web technology.

o       Describes techniques that are felt to be "sufficient' to meet the
success criteria - and would thus provide authors with "safe harbor" in
interpreting the SC.   

*         Authors can use other techniques but would then have to defend
their decisions to others - (managers, purchasers, courts).  If they use the
techniques described in the techniques document - they don't have a
normative interpretation but they have an technique which has very high face
validity for meeting the SC. 

o       Provides additional techniques or advice that go beyond SC
requirements but that would increase accessibility for some or all sites.
These ADVISORY TECHNIQUES may or may not be testable.


Techniques Notes:


o       Techniques doc does not provide any additional requirements

o       Techniques doc does not say what is required for conformance (the SC
do that) but only helps users understand the SC

e.g.   SC says that a standard and supported method must be used for X.  The
techniques document would tell the user what the HTML standard says is the
standard way to do it.  It would also indicate when a technique was or
wasn't supported by current technologies. 

o       Clear delineation between 4 technique types

1.      Techniques which meet success criteria

2.      Techniques to compensate for current User Agent (including AT)
shortcomings [ADVISORY - Not needed to meet SC]

3.      Techniques to build access for future (but aren't supported widely
yet) [ADVISORY]

4.      Additional techniques for making content more accessible  [ADVISORY]

*         Not necessarily testable or applicable to all or even most
content. 

 


Tests


Purpose


-          Provide a method for testing to determine whether particular
techniques have been done properly.  


Notes on Tests


-          They may include automated or manual tests.   

-          They may include tests for techniques needed to conform to SC for
a given technology, as well as tests for ADVISORY TECHNIQUES.   

-          Tests do not prove conformance to a SC (or guideline), only that
a technique has been done.    

 


Checklist 


Purpose


-          To provide a simple list of all the success criterion in a form
that they can be checked off or annotated


Notes on Checklists


-          Checklists must include all level 1 SC.

 


Annotated Checklist


Purpose


-          To provide a checklist with additional information for each
Success Criterion to make it easier to understand what needs to be done,
and what tools, techniques or methods are available to meet the SC 


Notes on Annotated Checklists


-          the additional information may include

*    information needed to understand how the SC would apply to different
technologies 

*    techniques that would meet the SC

*    advisory techniques that go beyond what is needed to meet the SC

*    links to tests for the techniques (required and/or advisory)

 

 

 





Received on Thursday, 10 March 2005 17:33:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:36 GMT