W3C home > Mailing lists > Public > w3c-wai-au@w3.org > April to June 2014

RE: Draft text intro to How to Meet WCAG 2.0 for ATAG 2.0 testers

From: Boland Jr, Frederick E. <frederick.boland@nist.gov>
Date: Tue, 3 Jun 2014 14:04:04 +0000
To: "Richards, Jan" <jrichards@ocadu.ca>, "w3c-wai-au@w3.org" <w3c-wai-au@w3.org>
Message-ID: <b450acda74744c2f8df04107ff8ff824@BN1PR09MB0188.namprd09.prod.outlook.com>
Thanks Jan great job.. 

In the following, to avoid any unintended misinterpretations/redefinitions of what WCAG says,  I would just refer to How to Meet WCAG 2.0:  http://www.w3.org/WAI/WCAG20/quickref/  (as I think you allude to) as is without further clarification, and then describe any specific deviations needed for ATAG 2.0 as "deltas" from that document, along with rationale for the specific deviations.   May also want to specifically refer to WCAG 2.0 Conformance section: http://www.w3.org/TR/WCAG20/#conformance
(along with any specific deviations from that section as well), since you mention WCAG2.0 requirement under "usage notes" and will give context..  The reason I bring this up is that as I remember in Eval TF we've had to be careful at times about inadvertently redefining WCAG 2.0 in creating/describing that methodology..

 Also, it is possible that new techniques/failures for existing and new technologies will be added to WCAG2.0 documentation in the future (techniques document is a moving target), the techniques/failures themselves are non-normative, and there may be good techniques out there for these other technologies.  So do we want to exclude them at this time?    We want to encourage authoring tools to satisfy ATAG now and in the future, right?    

Do we want to say you "must" use manual tests in all instances?  I think should be VERY STRONGLY recommended, but just wondering.. "must" seems like a strong word..?  

Thanks and best wishes
Tim Boland NSIT

-----Original Message-----
From: Richards, Jan [mailto:jrichards@ocadu.ca] 
Sent: Monday, June 02, 2014 4:06 PM
To: w3c-wai-au@w3.org
Subject: Draft text intro to How to Meet WCAG 2.0 for ATAG 2.0 testers

For today's action item....

Web Content Accessibility Test Procedure (Level A, AA, AAA):

Many ATAG 2.0 success criteria refer to meeting WCAG 2.0 success criteria. In order to test these success criteria, you will need a Web Content Accessibility Testing Procedure that is: (a) specific to the "included" web content technology (e.g. HTML, CSS, SVG, etc.) produced by the authoring tool and (b) designed to test WCAG 2.0 conformance to at least the target level (e.g. Level AA). 

For the purposes of CR testing, it is recommended that you refer to "How to Meet WCAG 2.0: A customizable quick reference to Web Content Accessibility Guidelines 2.0 requirements (success criteria) and techniques". This is the most complete and comprehensive WCAG 2.0 testing resource published by the W3C. 

Usage Notes:
- You should begin by customizing "How to Meet WCAG 2.0" with the relevant sections, so that irrelevant information is not displayed (e.g. techniques for other web technologies, success criteria with higher levels than the target level)
- The "Sufficient Techniques" and "Failures" will likely be more important in testing than the "Advisory Techniques" . However, there may be other ways to meet success criteria besides the sufficient techniques in W3C's Techniques for WCAG 2.0 document (http://www.w3.org/TR/2014/NOTE-UNDERSTANDING-WCAG20-20140311/understanding-techniques.html#ut-understanding-techniques-sufficient-head)
- While you can use automatic testing tools, you must also use manual tests in order to be sure of the results.
- The WCAG 2.0 requirement that "only accessibility-supported ways of using technologies are relied upon to satisfy the WCAG 2.0 success criteria" does not need to be applied as described in ATAG 2.0 section Relationship to the Web Content Accessibility Guidelines (WCAG) 2.0.

Only authoring tools producing technologies with Techniques in the "How to Meet WCAG 2.0" document will be included in ATAG 2.0 CR testing.


T 416 977 6000 x3957
F 416 977 9844
E jrichards@ocadu.ca
Received on Tuesday, 3 June 2014 14:04:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:28:49 UTC