BenToWeb Test Case Description Language (TCDL) 1.1

Formal Metadata

The formal or administrative metadata that can be stored are:

• description (mandatory; W3CTM);
• title (mandatory; W3CTM);
• author (mandatory; W3CTM);
• language (mandatory);
• rights (mandatory; W3CTM) — usually BenToWeb copyright;
• creation date (mandatory);
• status (mandatory; W3CTM): “draft”, “pending bugfix”, “accepted for end user evaluation”, “evaluated by expert”, “evaluated by end user” or “accepted”;
• version (optional);
• source (optional): if the test file is borrowed from an existing test suite, the test suite and the URL of the original test file can be documented; in addition, it is possible to indicate
  • if the borrowed file was modified and
  • to document these modifications and other comments, and
  • rights (for example copyrights; W3CTM) related to the borrowed file.

Technologies

BenToWeb uses the term “technology” in the same sense as WCAG 2.0: a data format, programming or markup language, protocol or API. TCDL provides the ability to store the following information about technologies used in a test:

• the formal specification or recommendation that defines the technology (by name and URL; mandatory);
• the technology features (for example, which XHTML elements and/or attributes) that are relevant to the test (optional);
• a reference (URL) to a section in the formal specification or a quote from the formal specification that describes the technology features that are relevant to the test (optional).

Test Case

Rules

This section contains the “rules” that are tested by a test case. In BenToWeb, rules are generally WCAG 2.0 success criteria, but it is also possible to reference other sets of “rules”:

• WCAG 1.0 checkpoints,
• Section 508 provisions,
• BITV provisions.

The rules do not provide a direct reference to the relevant online source because it may not always be possible to reference “rules” directly (for example, because they are not available in HTML). The rules reference a rule ID in a “Rulesets XML” file (see Rulesets XML RDDL document), which in turn references the relevant rule in an online source.

For each rule listed in this section, the following information can be provided:

• whether the rule is the “primary” rule of the test case or only listed for informative purposes (for example, some test cases uses invalid markup in tests that are not about validity, so it is useful to document that checkpoints about validity should not be applied to the test case) (optional);
• the identifier of the rule in “Rulesets XML” (mandatory);
• the locations in the test file that are relevant to the rule, with URL, line number, column number and/or XPath expression (optional);
• whether the test case passes or fails the success criterion or rule;
• the functional outcome of the test: a description of why the test case passes or fails, in terms that relate to a user's experience (as opposed to technical comments about source code) (mandatory);
• technical comment on the test: a technical description of why the test case passes or fails, and other technical information (for example, issues in certain browsers or assistive technologies).

Namespace Mappings

This optional section is important for test cases based on test files that use XML-based technologies. The technology features (see the section on Technologies above) used in a test case exist in an XML namespace and should be referenceable with XPath. The normal mechanism for mapping namespaces to URIs by declaring them with xmlns:prefix="namespaceURI" cannot be used for this, because it is necessary to be able to define empty prefixes and to extract the namespace mappings with a common XML API.