- From: Tim Boland <frederick.boland@nist.gov>
- Date: Tue, 12 Jul 2005 09:51:54 -0400
- To: w3c-wai-gl@w3.org
Per my "action item" from July 6 WCAG TTF teleconference, here are some thoughts: (1) Perhaps it should be a goal that each technique should have a documented test assertion, derived from the technique's task, test files, and examples; this assertion would attempt to objectively define (measure) what it means for a technique to be "successful" relative to the "related" WCAG2.0 success criterion. For more information on test assertions, please consult QA SpecGL Good Practice 12 [1] . (2) Perhaps it should be a goal that each technique should have documented (possibly as part of the test assertion or as an extension to it) exactly and specifically how such "success" as measured in (1) previous would "satisfy" the relevant WCAG2.0 success criterion. For example, for those techniques "related" to WCAG2.0 G1.3L1SC1 [2], language could be included as "Structures within the content are programmatically determined because...and then insert language "derived from" test assertion" of "related" technique(s)? (3) Perhaps there should be a more "formal" process by which techniques are evaluated and approved for promoting WCAG2.0 conformance, to ensure not only that the requirements specified in Requirements for WCAG2.0 Checklists and Techniques [3] are met, but also that conditions (1) and (2) mentioned previously are satisfied (since the techniques will actually be "tested" to support WCAG2.0 conformance). Perhaps any techniques that do not meet the previously-mentioned requirements should be placed in a different category from those that do? (4) Perhaps there should be consideration as to whether appropriate "metadata" (with definitions for all applicable terms) could be used in managing baseline information related to techniques (to attempt to manage the "complexity" related to baseline description?). A proposed QA Wiki test case metadata set of terms [4] might serve as illustration for this approach (since baseline is related to techniques which is related to testing?); perhaps some of these terms are even applicable to baseline management as well. I think there may need to be a consistent methodology for managing the "complexity" of baseline information in techniques. (5) Testing of accessibility issues implemented in a technology may have different aspects than testing the basic features of the referenced technology itself, and so I think these aspects may need to be distinguished in "testing" the techniques. For more information on testing per this point, please consult QA Test FAQ [5] and the QA Wiki topics on "Building a Test Suite [6]. Thanks and best wishes Tim Boland NIST PS - I've started work on some test files for CSS techniques, and this work, along with the discussions on scripting techniques at the previous TTF, has stimulated thoughts on the previously-mentioned points. [1]: http://www.w3.org/TR/2005/PR-qaframe-spec-20050629/#write-assertion-gp [2]: http://www.w3.org/TR/WCAG20/#content-structure-separation [3]: http://www.w3.org/TR/wcag2-tech-req/ [4]: http://esw.w3.org/topic/TestCaseMetadata [5]: http://www.w3.org/QA/WG/2005/01/test-faq [6]: http://esw.w3.org/topic/QA
Received on Tuesday, 12 July 2005 13:54:34 UTC