Discussion Notes: technology-specific "checkpoints"

Background | Testable assertions by success criteria

Background

5 Sept 2002 discussion

This document provides background and proposals to fulfill an action item taken by andi snow-weaver, john slatin, paul bohman, wendy chisholm, and ben caldwell at the 5 September 2002 telecon.

During this telecon, we discussed the wording of existing "rules" in the HTML Techniques (last draft published March 2002). for example:

Use the TITLE element to describe the document.
Use the ADDRESS element to define a page's author.
Use CSS, not HTML header elements, to create font effects.

It was felt that these types of statements were not appropriate for inclusion in a checklist since they are not testable assertions.

Relation to "Techniques for Accessibility and Evaluation and Repair Tools" (AERT)

Most of these rules are based on checks from the AERT document (no longer under development since this work supercedes it). For example, AERT provides the following techniques for evaluating WCAG 1.0 Checkpoint 1.1:

Technique 1.1.1 [priority 1] Check IMG elements for valid "alt" attribute
- followed by which HTML elments should trigger the checks for valid alt attribute values and defines valid alt attributes.
Technique 1.1.2 [priority 1] Verify that valid IMG element descriptions ("longdesc" attribute or d- link) are provided where necessary.
Technique 1.1.3 [priority 1] Check INPUT elements of type="image" for valid "alt" attribute
Technique 1.1.4 [priority 1] Check APPLET elements for valid HTML equivalent
Technique 1.1.5 [priority 1] Check OBJECT elements of type="image_MIME_types" for valid text equivalents and descriptions (where necessary)
there are 12 techniques total. I will not replicate all of them here.

WCAG 2.0 success criteria

The WCAG 2.0 Working Draft designates success criteria for each checkpoint and moves the priority level from the checkpoints to the success criteria. For example: Checkpoint 1.1 (For all non-text content that can be expressed in words, provide a text equivalent of the function or information the non-text content was intended to convey.) has the following success criteria (at the minimum level):

non-text content that can be expressed in words has a text-equivalent explicitly associated with it.
non-text content that can not be expressed in words has a descriptive label provided as its text- equivalent.
- The text equivalent should fulfill the same function as the author intended for the non-text content (i.e. it presents all of the intended information and/or achieves the same function of the non-text content).

Checklists

Discussion about technology-specific checklists began at the Linz F2F resulting in mock-ups and mailing list discussion.

Other checklist formats to consider:

Testing terminology

from y by Hung Q. Nguyen (2001).

Test case: A test that (ideally) executes a single well-defined test objective (i.e., a specific behavior of a feature under a specific condition).
Test script: Step-by-step instructions that describe how a test case is to be executed.
Test suite: A collection of test scripts or test cases that is used for validating bug fixes (or finding new bugs) within a logical or physical area of a product.
Test specification: A set of test cases, input, and conditions that are used in the testing of a particular feature or set of features. A test specification often includes descriptions of expected results.
Test requirement: A document that describes items and features that are tested under a required condition.
Test plan: A management document outlining risks, priorities, and schedules for testing.

Testable assertions by success criteria

This first example contains assertions similar to what is found in AERT.

Checkpoint 1.1 For all non-text content that can be expressed in words, provide a text equivalent of the function or information the non-text content was intended to convey.

Minimum Level Success Criterion	Pass	Fail	N/A
1.1.1 non-text content that can be expressed in words has a text-equivalent explicitly associated with it.

Techniques for SC 1.1.1

HTML Techniques	applied	not applied

Each `IMG` element has an `alt` attribute.
For spacer images, the value of the `alt` attribute is "" (null alt-text).
For graphs, charts, and maps, the value of the `alt` attribute follows the guidelines from the National Braille Association. (@@write testable assertions that summarize all of that info)

Or, we could make general assertions. In this example, a general statement is made followed by element and attribute-specific requirements for a variety of formats. Following that are further tests about different types of media and descriptions of appropriate text equivalents.

Core Techniques	applied	not applied

Each element that references an image has a valid text equivalent. Technology-specifics: HTML: each IMG element as a valid "alt" attribute. HTML: where necessary, IMG elements have a valid "longdesc" attribute. HTML: each OBJECT element has valid content. SMIL: all (?) image, video, audio elements have a valid "alt" attribute.
For spacer images, the value of the text equivalent is "" (null alt-text).
For graphs, charts, and maps, the value of the text equivalent follows the guidelines from the National Braille Association.

Use the body of the `OBJECT` element to provide a text equivalent for image objects.

Questions

How do we want to express these? Is the appropriate form:
- each X has a Y
- for every X there exists a Y
- if X then Y

$Date: 2002/09/14 01:14:30 $ Wendy Chisholm