W3C home > Mailing lists > Public > w3c-wai-au@w3.org > July to September 2012

Towards a description of ATAG 2.0's approach to testing

From: Richards, Jan <jrichards@ocadu.ca>
Date: Mon, 17 Sep 2012 18:47:31 +0000
To: "w3c-wai-au@w3.org" <w3c-wai-au@w3.org>
Message-ID: <0B1EB1C972BCB740B522ACBCD5F48DEB03AECAC7@ocadmail-maildb.ocad.ca>
This is just the start of a draft...

ATAG 2.0 presents a major testing challenge due to the interplay of the factors listed. After each factor, mitigating strategies will be listed that will be followed in developing ATAG 2.0 CR exit criteria and tests to support those criteria:

1. the conforming entities are authoring tools, which may be extensive and which may consist of compiled code, making testing whole-tool statements (e.g. that all controls implement accessibility APIs) very difficult, especially for outsiders.
-  the ATAG2 tests may require the type of access that only a developer might have

2. The authoring tool may run on any number of platforms.
- the ATAG2 tests will not specify precisely how to make an application accessible on each particular platform. Instead, the tests will specify that the evaluator must have a "Platform Accessibility Service Test Procedure" ready before they start (@@@and that the test procedure should be described).

3. in many places, ATAG 2.0 refers to WCAG 2.0 as the recommendation that authoring tools and authors should be seeking to meet in the produced content (and with the authoring interface). However, WCAG 2.0 itself points to its WCAG 2.0 for implementation guidance with respect to particular formats, but with the important proviso that techniques are non-normative. Furthermore, not all formats have WCAG 2.0 Techniques yet:
- the ATAG2 tests will not specify precisely how to meet WCAG 2.0. Instead, the tests will specify that the evaluator must have a " Web Content Accessibility Test Procedure" ready before they start (@@@and that the test procedure should be described).

4. in many cases, for clarity, the ATAG 2.0 SCs are written in uncompromising language, but this could see even well-implemented products fail for bugs or pockets of little used functionality that have not yet been updated for accessibility.
- @@@



(MR) JAN RICHARDS
PROJECT MANAGER
INCLUSIVE DESIGN RESEARCH CENTRE (IDRC)
OCAD UNIVERSITY

T 416 977 6000 x3957
F 416 977 9844
E jrichards@ocadu.ca
Received on Monday, 17 September 2012 18:47:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 17 September 2012 18:47:55 GMT