Requirements for Techniques: Draft 0.2

Here is a draft of the requirements documents for Techniques. The chairs
have reviewed this and made some contributions, but not all their feedback
is yet incorporated into this draft, pending further discussion. I think
it's ready for the group to take an initial look and look forward to your
feedback. The draft is in the attached HTML document and copied in the email
below. Michael


Techniques must be structured in such a way that multiple views can be
achieved, including in particular: 

- Checklists

- Test files

- Techniques by conformance level

- Others?

This implies that Techniques must be highly structured and largely machine
manipulable. It is expected that they will exist in XML documents conforming
to the DTD/Schema in Appendix A.

Each Technique must be assigned a unique identifier to enable
machine-readable conformance statements.

Techniques must be usable by a variety of audiences, including in particular

- Content developers

- User agent developers

- Evaluation tool developers

- Authoring tool developers

- Assistive technology developers

- Others?

Each set of Techniques must apply to a distinct technology (e.g., HTML, CSS,
SVG, ECMAScript). 

There must be a separate Core Techniques document that will provide
information that is too specific for WCAG but not related to a specific
technology, such as:

- Mapping to Unicode

- Media equivalents for multimedia

- Clear and simple writing (4.1)

- Supplementing with non-text content (4.2)

- Summaries and definitions (4.3)

- Others?

Where technologies work together (e.g., HTML and CSS), relevant joint
techniques must be presented with the host technology (e.g., HTML). If
techniques do not involve interactions between the two technologies, they
must be presented with the techniques for their respective technology only. 

Techniques must state to which versions of the technology they apply, that
is, describe a practice to avoid or that will have a positive accessibility
impact. They may specify all versions, all versions prior to or later than a
particular version, or enumerate particular versions. 

Techniques may describe practices that are not yet supported by user agents,
authoring tools, etc. in order to provide guidance for tool developers. When
possible Techniques should also describe practices that work in contemporary
tools. 

Each technique must map to a specific WCAG Success Criterion or Additional
Ideas by URI and number for clarity and to enable auto generation of hybrid
Guidelines/Techniques documents.

There may be multiple techniques for each Success Criterion or Additional
Ideas, clearly stated that they are alternate techniques.

Each technique must state whether it fully implements the Success Criterion
or Additional Ideas and if not provide references to other techniques (in
the same or other Techniques documents) needed to complete the
implementation.

Techniques should be testable whenever possible and must declare whether
they are considered testable. Guidance about testing methods may be
provided.

Techniques must [should?] include or link to test cases showing positive and
negative implementations of the technique. [This implies the creation of a
test suite that exists at a layer below the Techniques layer.]

Techniques should include descriptions, commentary, implementation notes,
links to resources or training materials, etc. to contain information not
part of the structured data.

Techniques documents must be versioned in such a way that updates to the
documents do not break interdependencies that may exist among multiple
documents (e.g., on Core techniques, HTML dependent on CSS, etc.).

Michael Cooper
Accessibility Project Manager
Watchfire
1 Hines Rd
Kanata, ON  K2K 3C7
Canada
+1 613 599 3888 x4019
http://bobby.watchfire.com/