Test Case Description Language 2.0: Specification and Guide

Latest version: http://bentoweb.org/refs/TCDL2.0.html ($Date: 2009/05/04 11:05:13 $).

Editor: Christophe Strobbe (DocArch, Katholieke Universiteit Leuven).

Abstract

Test Case Description Language (TCDL) is an XML vocabulary for describing test files and evaluation scenarios for such test files, intended to be included in test suites for user interface guidelines such as Web Content Accessibility Guidelines (WCAG) 2.0.

Status of this Document

This is a draft! This document is not a final specification but can change based on practical experience with the language. It will also change to keep it synchronized with the HTTP Vocabulary in RDF.

Table of Contents

1. Introduction

This document defines the features and syntax of Test Case Description Language (TCDL). The objective of this language is to define metadata for test cases. In addition to formal metadata and links to relevant sections in technical specifications, TCDL also supports the definition of test scenarios for the validation of test samples (for example by end users) against usability and accessibility guidelines. TCDL defines metadata for detailed descriptions of test cases, for tracking the status of test cases during the development process, for matching test cases with user profile metadata, etcetera.

TCDL can be used to support the development of suites of test samples for sets of accessibility guidelines such as the Web Content Accessibility Guidelines 2.0 (WCAG 2.0).

2. Terms and Definitions

technology
Markup language, programming language, style sheet, data format, or API. (Source: WCAG2.0.)
test case
An individual test that corresponds to a test purpose, which in turn maps back to the assertion(s), and finally the spec. (Source: W3C QA Voc.)
In this context: test sample or set of tet samples that correspond to a test purpose, which maps to one or more statements in one or more specifications (technical specifications on the one hand, usability or accessibility specifications on the other).
test sample
An example or set of examples (in specific content formats) that demonstrates correct or incorrect implementation of a statement in a technical specifcation and/or a set of usability or accessibility guidelines.
test suite
A set of documents and tools providing tool developers with an objective methodology to verify the level of conformance of an implementation for a given standard. (Source: W3C QA Voc.)

3. How to Read this Specification

This specification reuses element and attribute types from other specifications. These element and attribute types can be recognized by the namespace prefixes that precede the names (for example, html:, dc:, xlink:). TCDL files need not use the same namespace prefixes as this specification, except where the namespace prefix is xml:, which is reserved by the XML specification (XML 1.0). References to data types defined in XML Schema Part 2: Datatypes consistently use the xs: namespace prefix.

The content models for the element types state whether a child element type is optional or required; child element types are not repeatable unless this is explicitly stated.

This specifcation uses certain keywords as defined in RFC 2119 to indicate requirement levels; these keywords are emphasized like the following examples: must, must not, should.

4. The Global Structure of a TCDL File: the testCaseDescription Element Type

The root element type of a TCDL file is testCaseDescription. This element type has the following attributes and namespace declarations:

Note: the namespace prefixes need not be the same as those in the above list, except for xml and xmlns.

Note: at the time of writing, EARL 1.0 is a working draft, and the final namespace URI may be different from the one above.

Note: for extensibility, the testCaseDescription element type can have any other attribute types in any namespace other than the target namespace (http://bentoweb.org/refs/TCDL2.0/); schema processors will validate attributes for which they can find declarations and raise errors if they are invalid (<xs:anyAttribute namespace="##other" processContents="lax"/>).

TCDL metadata are organised in five major sections, which will be explained below:

In addition, there are also several extension elements and extension points. See “Versioning XML Vocabularies” (Orchard 2003) and “Extensibility, XML Vocabularies, and XML Schema” (Orchard 2004) for more background on the extensiblity of XML vocabularies.

Below is the skeleton of a TCDL file.

<?xml version="1.0" encoding="UTF-8"?>
<testCaseDescription id="wcag20060427_sc1.1.1_l1_001"
  xml:lang="en"
  xmlns="http://bentoweb.org/refs/TCDL2.0/"
  xmlns:btw="http://bentoweb.org/refs/TCDL2.0/"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:xlink="http://www.w3.org/1999/xlink"
  xmlns:html="http://www.w3.org/1999/xhtml"
  xmlns:earl="http://www.w3.org/WAI/ER/EARL/nmg-strawman#"
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:http="http://www.w3.org/2006/http#"
  xsi:schemaLocation="http://bentoweb.org/refs/TCDL2.0/ http://bentoweb.org/refs/schemas/tcdl2.0.xsd
    http://purl.org/dc/elements/1.1/ http://dublincore.org/schemas/xmls/qdc/2006/01/06/dc.xsd
    http://www.w3.org/1999/xhtml http://www.w3.org/2004/07/xhtml/xhtml1-strict.xsd
    http://www.w3.org/1999/xlink http://bentoweb.org/refs/schemas/xlink.xsd
    http://www.w3.org/2006/http# http://bentoweb.org/refs/schemas/http.xsd
    http://www.w3.org/WAI/ER/EARL/nmg-strawman# http://bentoweb.org/refs/schemas/earlwd.xsd"
  >
  <formalMetadata>
    <!-- child elements omitted -->
  </formalMetadata>
  <technologies>
    <!-- child elements omitted -->
  </technologies>
  <testCase>
    <!-- child elements omitted -->
  </testCase>
  <rules>
    <!-- child elements omitted -->
  </rules>
  <namespaceMappings>
    <!-- child elements omitted -->
  </namespaceMappings>
</testCaseDescription>

Note: There is no normative schema for XLink; see Appendix B of the XLink specification (XLink 1.0). In the BenToWeb project, the W3C XML Schema for XLink 1.0 (METS XLink Schema, v. 2, Nov. 15, 2004), from the Metadata Encoding and Transmission Standard (METS) Official Web Site (Library of Congress) was borrowed with permission.

5. Formal Metadata: The formalMetadata Element Type

The formalMetadata element type contains formal or administative metadata.

This element type has the following attribute types:

The formalMetadata element type also has a number of required and optional child element types, which occur in the following order:

5.1. The title Element Type

The title element type contains the title of the test case. It does not need to be unique (for example, in the test suite containing the test case) and its lenght can vary depending on the complexity of the test materials. However, the title should be sufficiently descriptive to allow a quick identification of the issue exhibited by the test case.

This element type has the following attribute types:

This element type may not only contain character data but also the XHTML element types specified in XHTML-Style Inline Markup.

5.2. The dc:creator Element Type

The dc:creator element type is borrowed from the Dublin Core Metadata Element Set (DCMES 1.1) and identifies the person or organization primarily responsible for creating the test case.

This element type has no attribute types.

The dc:creator element type has the data type xs:string and must therefore contain only character data.

5.3. The dc:contributor Element Type

The dc:contributor element type identifies the person or organization responsible for making contributions to the content of the test case.

This element type has no attribute types.

The dc:contributor element type has the data type xs:string.

5.4. The dc:language Element Type

The dc:language element type is borrowed from the Dublin Core Metadata Element Set (DCMES 1.1) and identifies the language of the intellectual content of the test case.

This element type has no attribute types.

The dc:language element type has the data type xs:string and must therefore contain only character data. However, in TCDL the value of dc:language must be one of the language tags defined by BCP 47 (the successor of RFC 3066). The value must not be empty or null.

5.5. The dc:rights Element Type

The dc:rights element type is borrowed from the Dublin Core Metadata Element Set (DCMES 1.1) and describes rights held in and over the test case.

This element type has no attribute types.

The dc:rights element type has the data type xs:string and must therefore contain only character data.

5.6. The dc:date Element Type

The dc:date element type identifies the date when the test case was created.

This element type has no attribute types.

The dc:date element type has the data type xs:date (which is inspired by ISO 8601) or uses the CVS Date command. Examples: 2004-10-01 means 1 October 2004; $ Date: 2008/07/16 14:42:48 $ means 16 July 2008, 2.42 am.

5.7. The status Element Type

The status element type identifies the state of the test case during the development process of the test suite, by means of one of an enumerated list of values (for example, “draft”, “pending bugfix”, “accepted”, “rejected”).

This element type has no attribute types.

The status element type has the data type xs:string, but the values should really be chosen from a limited list. Defining the list of legal values is outside the scope of this specification because these values depend on the context of the test suite. For an example, see the Conformance Test Process For WCAG 2.0, which contains a description of the steps that must be performed so that a test case may be added to a test suite for WCAG 2.0.

5.8. The version Element Type

The version element type contains an identifier that allows one to distinguish between different revisions of a test case. Note that the W3C QA Framework Primer defines a new version of a specification as a significant functional change and enhancement. TCDL does not define what consitutes a new version of a test case because this depends on the context in which the language is used.

Note: the WG Note on Test Metadata contains the following note about “version”:

ISSUE: It is unclear whether it is necessary to apply version numbers to individual tests. More common practice is to version the entire test suite. Ideally tests will not need to be revised as the specification evolves. However, this is sometimes necessary, and at a minimum each Working Group should define SpecRef and possibly other metadata such as Grouping elements to indicate which versions of the specification an individual test supports.

This element type has no attribute types.

The version element type has the data type xs:string.

5.9. The source Element Type

The source element type is used to document the source of a borrowed test case and related information: the name and URL of the original test suite, the URL of the original test file, its creator, whether the file was copied literally or with changes, and rights held in and over the original test case.

This element type has the following attribute types:

The source element type can only contain other element types in the following order:

5.9.1. The testSuite Element Type

The testSuite element type is used to document the test suite from which a test case was borrowed.

This element type has the following attribute:

The testSuite element type can only contain one element type (and no character data):

This element type may not only contain character data but also the XHTML element types specified in XHTML-Style Inline Markup.

5.9.2. The sourceFile Element Type

The sourceFile element type is used to document a file that was borrowed from another test suite.

This element type has the following attribute types:

The sourceFile element type can only contain one element type (and no character data):

The dc:creator element type identifies the person or organization primarily responsible for creating the borrowed test file. For attribute types and content model, see the dc:creator element type above.

5.9.3. The dc:rights Element Type

The dc:rights element type describes rights held in and over the borrowed test file. For attribute types and content model, see the dc:rights element type above.

5.9.4. The comment Element Type

The comment element type is a general-purpose container for comments on the borrowed materials, such as changes that were performed, errors that were found etcetera.

This element type can only contain XHTML-style paragraphs.

6. Technologies: The technologies Element Type

The technologies element type contains the following information about the technologies used in a test case:

This element type has the following attribute types:

The technologies element type contains one or more instances of the technicalSpec element type.

6.1. The technicalSpec Element Type

The technicalSpec element type identifies a technology (proprietary, W3C recommendation or other type of technical specification) used in the test case. If a test case uses server-side scripting to generate content on the fly, technicalSpec identifies the generated content type, not the server-side scripting language. Languages and formats that are embedded or inlined in another format, for example inline CSS or an embedded PNG file in an HTML file are also considered as technologies in the context of this specification. There is one technicalSpec element for each file technology used by the test case.

This element type has the following attribute types:

The xlink:href attribute type contains the URL of the technical specification of the file format. Examples:

According to the XLink 1.0 specification,

[t]he value of the href attribute must be a URI reference as defined in RFC 2396, or must result in a URI reference (…).

The baseline attribute type specifies whether a technology (technicalSpec) or a feature (testElement) is inside or outside the baseline assumed by the test case. The value “included” means that something is inside the baseline; the value “excluded” means outside the baseline. (For information about baselines in WCAG 2.0, see “Technology assumptions and the "baseline"” in Web Content Accessibility Guidelines 2.0 (WCAG 2.0 - W3C Working Draft 27 April 2006) and About Baselines and WCAG 2.0.) See the section Describing Baselines (below) for a fuller explanation and examples.

Note: at the time of writing [@@date], it is not entirely clear whether WCAG baselines will only contain complete technologies or also mention specific features. The issue was discussed in March 2007, with some arguments in favour of very granular baseline information. WCAG conformance claims don’t need to specify what technologies were used outside the baseline, but it seems desirable that test case metadata are more precise in this area.
The May 2007 Working Draft of WCAG 2.0 replaced the baseline concept with “accessibility-supported technology”.

The handle attribute type supports the use of a short string that uniquely identifies the technology. This attribute can be used when technologies need to be identified by means of string comparison, especially when comparing URIs is too cumbersome or inappropriate. If the handle is also diplayed in a user interface, it is advisable to use strings that can be easily recognised by users.

The mediatype attribute type specifies the MIME media type of the format identified by the technicalSpec element, if a MIME type is available. Some MIME types have been registered by IANA (IANA). For other MIME types it may be necessary to consult vendor documentation or Wikipedia.

Note: the requirement that there is a formal specification or recommendation for each technology works for many technologies (HTML, CSS, ECMAScript, Flash, PDF, PNG, JPEG) but may be more problematic for others (vendor-specific HTML extensions, the currently non-standerdized XMLHttpRequest object, …).

The technicalSpec element type can contain two other element types:

For example, to refer to XHTML 1.0, one could write:

<technicalSpec xlink:href="http://www.w3.org/TR/xhtml1/">
<specName><html:acronym>XHTML</html:acronym>&#8482; 1.0: The Extensible HyperText Markup Language (Second Edition)</specName>
</technicalSpec>

6.1.1. The specName Element Type

The specName element type contains the name of the technology, more specifically the title of the technical specification that defines the technology. This element type may not only contain character data but also the XHTML element types specified in XHTML-Style Inline Markup.

6.1.2. The testElements Element Type

The testElements element type contains a description of the elements or features used by the test case. This element can be omitted for binary formats (PDF, Flash, …).

Note: this element type allows developers to check how well a test suite covers certain features, especially accessibility features, of a technology.

The testElements element type has no attribute types. It contains at least one instance of the testElement element type.

6.1.2.1 The testElement Element Type

The testElement element type contains a description of a specific element or feature. There is one testElement for each feature used by the test case. For CSS, the name of the rule, selector, property, property value, … can be provided. For proprietary element and attribute types (Microsoft’s bgsound, Netscape’s embed, etcetera), a link to the company’s documentation can be provided.

The testElement element type has an optional baseline attribute. It also contains one instance of the elementName element type, followed by one instance of either the specReference element type or the specQuote element type.

The elementName element type identifies the name of the element or feature. This element type has the following attribute types:

The localname attribute type identifies the name of the feature. If the feature is an element or attribute from an XML vocabulary, localname contains the unqualified name.

The namespace attribute type identifies the namespace URI of the feature, if relevant. This attribute type must not be used if the technology defining the feature is not an XML vocabulary.

elementName is an empty element type; it does not contain child elements or characer data.

The specReference element type contains the title of the relevant section in the specification. Use the title provided by the specification wherever possible; otherwise provide a succinct and meaningful title for the relevant section in the specification.

This element type has the following attribute types:

The xlink:href attribute type contains the URL of the relevant section in the technical specification.

Examples of xlink:href in specReference:

The specReference element type may not only contain character data but also the XHTML element types specified in XHTML-Style Inline Markup.

The specQuote element type contains a quote from the relevant section of the specification. specQuote can be used if it is not possible to provide an exact pointer to the relevant section in the specification (with specReference).

This element type has the following attribute types:

The specQuote element type may not only contain character data but also the XHTML element types specified in XHTML-Style Inline Markup.

6.2. Describing Baselines

The Web Content Accessibility Guidelines 2.0 (WCAG 2.0, Working Draft 27 April 2006) defines a baseline as the

set of technologies assumed to be supported by, and enabled in, user agents.

The concept of baseline is intended to allow the use of newer technologies with accessibility features, instead of implicitly defining a baseline of HTML 4/XHTML 1.0 and CSS 1.0 (without JavaScript, Flash, PDF etcetera) as WCAG 1.0 did. A conformance claim for WCAG 2.0 must include a description of the baseline. To enable the description of a baseline for a test case, TCDL has the baseline attribute type on the technicalSpec element type. However, support for a technology is rarely, if ever, complete. For example, in HTML 4 the element types object and link and the attribute type longdesc were not widely supported for a long time (or at least not in the browser that dominates the market). For this reason, TCDL also enables the exclusion of certain element or attribute types from a technology that is in the baseline, by means of the baseline attribute type on the testElement element type.

For example, Techniques for WCAG 2.0 contains technique H60: Using the link element to link to a glossary. If the test case author assumes that link is well supported, the technologies section can simply look as follows:

<technologies>
  <technicalSpec xlink:href="http://www.w3.org/TR/xhtml1/" baseline="included" mediatype="text/html">
    <specName>
      <html:acronym>XHTML</html:acronym>&#8482; 1.0: The Extensible HyperText Markup Language (Second Edition)
    </specName>
  </technicalSpec>
</technologies>

However, if the test case author assumes that link is not sufficiently supported, it is possible to exclude this element type in the following manner:

<technologies>
  <technicalSpec xlink:href="http://www.w3.org/TR/xhtml1/" baseline="included" mediatype="text/html">
    <specName>
      <html:acronym>XHTML</html:acronym>&#8482; 1.0: The Extensible HyperText Markup Language (Second Edition)
    </specName>
    <testElements>
      <testElement baseline="excluded">
        <elementName localname="link" namespace="http://www.w3.org/1999/xhtml"/>
        <specReference xlink:href"http://www.w3.org/TR/1999/REC-html401-19991224/struct/links.html#edef-LINK">
          Document relationships: the <html:code>link</html:code> element
        </specReference>
      </testElement>
    </testElements>
  </technicalSpec>
</technologies>

7. Test Case: The testCase Element Type

The testCase element type describes what is necessary for the evaluation of the test case.

This element type has only one attribute type, complexity, with the values “atomic” or “complex”. A test case is atomic if it applies to only one “accessibility rule” (for example, a WCAG 1.0 checkpoint, a WCAG 2.0 success criterion or a Section 508 rule), or complex if it applies to multiple “accessibility rules” from the same set (i.e. the same guidelines document or the same set of legal requirements). The complexity attribute type is optional and its default value is “atomic”; in other words, a testCase element without a complexity attribute contains an atomic test case.

The testCase element type can contain six other element types:

7.1. The dc:description Element Type

The dc:description element type contains a summary of the test materials and how they are to be used in the test case. The description indicates to the accessibility expert/scenario author what to expect and what will happen when a user interacts with the test materials. The description of the behaviour is especially important for test materials with interactive components such as forms.

This element type has the following attribute types:

The dc:description element type may not only contain character data but also the XHTML element types specified in XHTML-Style Inline Markup.

Note: Strictly speaking, Dublin Core elements can only contain strings. The Notes on the W3C XML Schemas for Qualified Dublin Core state that “According to the schema, the values of XML elements representing Dublin Core elements and element refinements may only have simple "string" values (which may be further restricted in the manner described below), defined by the type dc:SimpleLiteral in the schema. (…) Complex or structured values - i.e., the use of additional XML elements nested within the XML elements representing Dublin Core elements and element refinements - are not valid. By exploiting features of the XML schema specification, the proposed schema are designed so that it is possible to import the schema into an extension schema that does allow additional nested elements as values for the Dublin Core elements. Such extensions will not be valid according to the container schema listed here and, therefore, not interoperable except by translation methods (not yet defined here or by the DCMI).”

7.2. The purpose Element Type

The purpose element type contains a description of the intention of the test materials. The purpose contains an explanation of the expected evaluation result in regard to the relevant rules, checkpoints or success criteria. It does not need to repeat the “rule” or success criterion for which the test case is developed. (Strictly speaking, this goes beyond the Purpose in W3C Working Group Note on Test Metadata.)

This element type has the following attribute types:

This element type can only contain XHTML-style paragraphs.

7.3. The internalNotes Element Type

The internalNotes element type contains any notes for internal use.

This element type has the following attribute types:

The internalNotes element type contains one or more occurrences of the internalNote element type.

7.3.1. The internalNote Element Type

The internalNote element type contains information for internal use. It has attributes that allow filtering and retrieval (id and class). This element type may not only contain character data but also the XHTML element types specified in XHTML-Style Inline Markup.

This element type has the following attribute types:

7.4. The expertGuidance Element Type

The expertGuidance element type contains guidance to reviewers (for example, accessibility experts if TCDL is used for a WCAG test suite) for evaluating the test case.

This element type has the following attribute types:

This element type can only contain XHTML-style paragraphs.

7.5. The preconditions Element Type

The preconditions element type contains conditions that must be met before this test is executed. See Preconditions in W3C Working Group Note on Test Metadata.

This element type is provided for extensibility; it can contain any elements in any namespace other than the target namespace (##other).

7.6. The requiredTests Element Type

The requiredTests element type describes

Note: in Bentoweb, each scenario has a mandatory identifier that is unique within the test case description. This identifier is necessary to map end user feedback to the scenarios.

The TCDL specification does not define any attribute types for the requiredTests element type but allows the use of any attribute types in any namespace other than the target namespace for extensibility.

The requiredTests element type can contain the following element types in the following order:

7.6.1. The testMode Element Type

The testMode element type specifies the type of evaluation that is required to get the test case “accepted”.

This element type has no attribute types and allows only string values (xs:string).

Note: BenToWeb uses the following test modes:

7.6.2. The scenario Element Type

The scenario element type specifies a scenario that can generate data for validating the test case. In TCDL, this element type is geared towards end-user evaluation of test samples. For this purpose, it is possible to define several types of questions (see below).

This element type has the following attribute:

The scenario element type can contain the following element types in the following order:

For dc:creator, dc:date and status, see above: the dc:creator element type, the dc:date element type, and the status element type.

7.6.2.1. The scenarioNotes Element Type

The scenarioNotes element type is a container for any kind of notes on the scenario, for example, its purpose.

This element type has the following attribute types:

The scenarioNotes element type can only contain XHTML-style paragraphs.

7.6.2.2. The userGuidance Element Type

The userGuidance element type contains additional guidance to the end user who evaluates the test case, especially with regard to the configuration of their user agent and/or assistive technology. The xml:lang attribute is required.

This element type has the following attribute types:

Note: the languages must match those used for the questions defined in the questions element. This means that for each language version of a question, there must be a corresponding language version of userGuidance, and vice versa, unless the scenario does not need user guidance (in which case there is no userGuidance element for any of the languages in which the questions are available).

This element type can only contain XHTML-style paragraphs.

7.6.2.3. The questions Element Type

The questions element type contains one or more question that can be presented to a human evaluator (an end user) to evaluate a test case. In this context, end-user evaluation is a method for getting feedback on a technique or a specific aspect of a technique’s implementation, for example, the use of certain elements and/or attributes to meet a WCAG 2.0 success criterion or a specific contrast ratio in a web page.

If the evaluation panel (a group of end-users not involved in the development of the test cases) is multilingual, it may be necessary to provide the questions in different languages. In that case, there should be one question or set of questions per language that needs to be supported. The use of different language versions for questions, user guidance and labels must be consistent: when any of these items is translated, each of the other elements (assuming that they are used) must also be translated.

This element type has the following attribute types:

The questions element type can contain only one of the following five element types, which are mutually exclusive:

7.6.2.3.1. The openQuestion Element Type

The openQuestion element type contains an open question with a textarea, which can be presented to a user.

This element type has the following attribute types:

The openQuestion element type contains the following element types, which occur in the following order:

The questionText element type has a required xml:lang attribute and an optional dir attribute. There is one questionText element per language in which the scenario needs to be available. As noted, above, the language versions of questionText must match those of userGuidance, if any user guidance is provided. The questionText element type can only contain XHTML-style paragraphs.

The space element type has two required attribute types: rows, which specifies the number of visible text lines, and columns, which specifies the visible width in average character widths. The values of the rows and columns attributes must be positive integers. The resulting text area must allow the user to enter more lines than specified by the rows attribute and longer lines specified by the columns attribute.

7.6.2.3.2. The yesNoQuestion Element Type

The yesNoQuestion element type contains a yes-no-question, with a third option (for options such as “Don't know”, “Not applicable”, etcetera).

This element type has the following attribute types:

The yesNoQuestion element type contains the following element types, which occur in the following order:

The questionText element type is defined above.

The element types optionYes and optionNo are empty element types with the following attribute types:

The element types optionYes and optionNo are empty because it is not necessary for TCDL to contain the strings “yes” or “no” (or any translations of these): the process that transforms the scenarios into a user interface can fill in these strings.

The optionOther element type specifies an alternative for “yes” or “no”, for example “I don’t know” or “Other”. There must be one “other option” for each language in which the questions are available. Unlike the element types optionYes and optionNo, optionOther has child elements: it can only contain XHTML-style paragraphs.

The optionOther element type has the following attribute types:

7.6.2.3.3. The yesNoOpenQuestion Element Type

The yesNoOpenQuestion element type contains a yes-no-question, with a third option (for options such as “Don’t know”, “Not applicable”, etcetera) and an open question with a text area. It is a combination of the yesNoQuestion and openQuestion element types defined above.

The yesNoOpenQuestion element type contains the following element types, which occur in the following order:

The element types questionText, optionYes, optionNo, optionOther and space are defined above.

7.6.2.3.3. The likertScale Element Type

The likertScale element type specifies a Likert scale.

The Usability First™ Usability Glossary defines Likert scale as follows:

a type of survey question where respondents are asked to rate the level at which they agree or disagree with a given statement. For example:

I find this software easy to use.

strongly disagree 1 2 3 4 5 6 7 strongly agree

A Likert scale is used to measure attitudes, preferences, and subjective reactions. In software evaluation, we can often objectively measure efficiency and effectiveness with performance metrics such as time taken or errors made. Likert scales and other attitudinal scales help get at the emotional and preferential responses people have to the design. Is it attractive, fun, professional, easy?

This element type has the following attribute type:

The default for display is vertical (for greater accessibility to screen readers). Dropdowns are not recommended if more than one choice needs to be selected.

The likertScale element type contains the following element types, which occur in the following order:

The likertLevel element type defines a level in the Likert scale.

The element has the following attribute types:

The likertLevel element type contains the following elements, which occur in the following order:

The label element type specifies the label associated with the choice. There is one label element per language in which the scenario needs to be available.

This element type has the following attribute types:

The label element type may not only contain character data but also the XHTML element types specified in XHTML-Style Inline Markup.

The value element type specifies the value to be submitted by the user. There is only one value element in every likertLevel, so that the same value is sent to the server, regardless the number of languages the label is available.

This element type has no attribute types. Its data type is xs:string.

7.6.2.3.4. The multipleChoice Element Type

The multipleChoice element type contains a multiple choice question. It is possible to limit the number of responses to one (for radio buttons) or to allow multiple reponses (for check boxes). This element type is strictly a generalisation of likertScale, which can be seen as a short-hand notation of a specific usage of multipleChoice.

The multipleChoice element type has the following attribute types:

The select attribute type defines whether the user can select one or multiple choices (i.e. one radio button versus multiple check boxes): if a multipleChoice element has a select attribute with the value “one”, the HTML equivalent is rendered as a set of radio buttons; if the select attribute has the value “multiple”, the HTML equivalent is rendered as a set of check boxes.

The multipleChoice element type contains the following element types, which occur in the following order:

The choice element type has the following attribute types:

The choice element type contains the following element types, which occur in the following order:

7.6.2.3.2. The experience Element Type

The experience element type specifies a user’s level of experience with the specified types of software. There are three categories of software: assistive technologies, user agents and devices. User agent also covers browser plugins.

The experience element type has no attribute types. It contains the following element types, which occur in the following order:

AssistiveTechnology, UserAgent and Device are empty element types. AssistiveTechnology lists assistive technologies such as screen readers, screen magnifiers, voice recognition software, alternative keyboards and alternative pointing devices. UserAgent here refers to any software that retrieves and renders Web content for users. This may include Web browsers, media players, plug-ins, and other programs — including assistive technologies — that help in retrieving and rendering Web content. Device refers to the hardware on which user agents and/or assistive technologies run: personal computers, personal digital assistants, mobile phones, AAC devices, etcetera.

Note: in BenToWeb, assistive technologies are not user agents but are a category of their own.

The element types AssistiveTechnology, UserAgent and Device have the following attribute types:

The attribute type minimumLevel specifies a user’s required level of experience with a certain software or device on a scale from 1 (low/novice) to 5 (high/expert). How these levels are established is outside the scope of this specification but depends on the context where TCDL is used. This attribute type contains integers from 1 up to and including 5.

The attribute type type specifies the type of software or device. This attribute type contains only character data (data type xs:string).

Note: BenToWeb uses the following values for type:

The attribute type product specifies a product in the category specfied in type.

The attribute type version specifies a version of the product specified in product. If the version attribute type is used, the product attribute type must also be used. The data type of version is xs:decimal.

7.6.2.3.2.1. Matching experience and User Profiles

The experience information in a TCDL file can be used to filter specific scenarios for users with a specific profile, so that it is possible to gather information on how a test case is used by someone with a specific browser, a specific screen reader, etcetera. For this to work, the system that matches scenarios to user profiles would need a matching algorithm like the following:

7.6.2.3.2.2. Using experience: Examples

A few examples of how to match scenarios to user profiles with the above algorithm are discussed below. For the sake of simplicity, we will disregard to minimumLevel attribute values.

<!-- example 1 -->
<AssistiveTechnology type="screenreader" minimumLevel="3"/>
<UserAgent type="browser" minimumLevel="1"/>

This matches all user profiles with a certain screenreader AND a certain browser.

<!-- example 2 -->
<AssistiveTechnology type="screenreader" minimumLevel="3"/>
<AssistiveTechnology type="alternative input devices" minimumLevel="3"/>
<UserAgent type="browser" minimumLevel="1"/>

This matches all user profiles with a certain screenreader AND an alternative input device AND a certain browser.

<!-- example 3 -->
<AssistiveTechnology type="screenreader" minimumLevel="3"/>
<UserAgent type="browser" product="Microsoft Internet Explorer" version="4" minimumLevel="1"/>
<UserAgent type="browser" product="Microsoft Internet Explorer" version="5" minimumLevel="1"/>
<UserAgent type="browser" product="Microsoft Internet Explorer" version="6" minimumLevel="1"/>

This matches all user profiles with a certain screenreader AND any of the specified versions of Microsoft Internet Explorer (4, 5 or 6, but not 5.5).

<!-- example 4 -->
<AssistiveTechnology type="screenreader" minimumLevel="3"/>
<AssistiveTechnology type="magnification software" minimumLevel="3"/>
<UserAgent type="browser" product="Microsoft Internet Explorer" version="4" minimumLevel="1"/>
<UserAgent type="browser" product="Microsoft Internet Explorer" version="5" minimumLevel="1"/>

This matches all user profiles with any screenreader AND any magnification software AND any of the specified versions of Microsoft Internet Explorer (4 or 5 but not 5.5).

<!-- example 5 -->
<AssistiveTechnology type="screenreader" product="JAWS" minimumLevel="3"/>
<AssistiveTechnology type="screenreader"product="Window-Eyes" minimumLevel="3"/>
<UserAgent type="browser" product="Microsoft Internet Explorer" version="4" minimumLevel="1"/>
<UserAgent type="browser" product="Microsoft Internet Explorer" version="5" minimumLevel="1"/>

This matches all user profiles with any version of JAWS or Window-Eyes AND any of the specified versions of Microsoft Internet Explorer (4 or 5 but not 5.5).

<!-- example 6 -->
<AssistiveTechnology type="screenreader" product="JAWS" minimumLevel="3"/>
<AssistiveTechnology type="Braille display" minimumLevel="3"/>
<UserAgent type="browser" minimumLevel="1"/>
<Device type="PC" minimumLevel="2"/>

This matches all user profiles with any version of JAWS AND any Braille display AND any browser AND a PC.

7.6.2.3.3. The disabilities Element Type

The disabilities element type specifies one or more disabilities to which the test case is relevant. This enables matching test cases with user profiles and prevents that end users get test cases that are irrelevant to them (for example, a test case on colour contrast should not be matched with a blind user).

The disabilities element type has no attribute types. It can only contain one element type:

The disability element type can only contain character data (data type: xs:string). Defining a list of disabilities is beyond the scope of this specification.

Note: BenToWeb uses a list of disabilities that contains the following values (non-exhaustive):

The values above are not based on the WHO’s International Classification of Functioning, Disability and Health (ICF). One must also take into account that many of these terms may be found objectionable by persons they are supposed to describe. For some of these terms it is hard to find equivalents in other languages; literal translations may have a different meaning than in English.

7.6.3. The files Element Type

The files element type contains information about each of the test files that make up the test case.In a XHTML test suite for WCAG 1.0 or 2.0, for example, there is usually only one XHTML test file per test case (not counting supporting files such as external stylesheets , images, etcetera), but some checkpoints or success criteria, for example, those on consistent navigation, consistent style etcetera, require a set of files.

The files element type has only one attribute type:

The sequential attribute type specifies whether the order of the files (if there are several) matters for the evaluation of the test case: “true” means that the files should be processed in the order in which they occur in the test case description; “false” means that the files can be processed in random order. The default value is “false”.

The files element type can only contain one element type:

7.6.3.1. The file Element Type

The file element type has the following attribute types:

The xlink:href attribute type specifies the URL of the test file or test sample. Supporting files such as included images, external style sheets and dummy pages to which forms are submitted (if only the form is relevant to the test) etcetera, need not be documented. (Only what the April 2006 Last Call Working Draft of WCAG 2.0 calls “Web units” and what more recent working drafts call “Web pages” needs to be listed.)

If test cases are organised so that TCDL data are in a directory “metadata” and sample files are in a directory called “testfiles” and these directories are both subdirectories of “xhtmltestsuite”, xlink:href can contain a relative URL, for example: ../testfiles/sc1.1.1_l1_001.html.

The hrefLang attribute type specifies the language of the file or sample identified by xlink:href (if the attribute is present) or httpRequest (explained below).

The file element type can contain one and only one of the following element types defined in HTTP Vocabulary in RDF:

Note: the old httpRequest element type has been replaced with HTTP Vocabulary in RDF.

Note that HTTP Vocabulary in RDF currently only has a temporary namespace URI (http://www.w3.org/2006/http#) which is very likely to change when the document is published as a W3C Working Group Note.

7.6.3.1.1. Common HTTP Request Properties

The elements from HTTP Vocabulary in RDF described below can all have the following child elements:

The http:requestURI element type represents an HTTP request URI as defined in section 5.1.2 of RFC 2616. The http:requestURI element type can contain one and only one of the following element types defined in HTTP Vocabulary in RDF:

Note that http:requestURI duplicates xlink:href on file.

@@todo add more details from HTTP Vocabulary in RDF.

7.6.3.1.2. The http:GetRequest Element Type

The http:GetRequest element type represents an HTTP GET request as defined in RFC 2616.

<!-- example 1 -->
<http:GetRequest>
  <http:requestURI>
    <http:absoluteURI>http://www.bentoweb.org/</http:absoluteURI>
  </http:requestURI>
  <http:version>1.1</http:version>
  <http:accept>text/html;q=1.0, */*;q=0.01</http:accept>
  <http:accept-language>de-DE;q=1.0, de;q=0.75, en-GB;q=0.5, en;q=0.25, *;q=0.01</http:accept-language>
</http:GetRequest>

7.6.3.1.3. The http:PostRequest Element Type

The http:PostRequest element type represents an HTTP POST request as defined in RFC 2616.

7.6.3.4. The http:PutRequest Element Type

The http:PutRequest element type represents an HTTP PUT request as defined in RFC 2616.

7.6.3.5. The http:HeadRequest Element Type

The http:HeadRequest element type represents an HTTP HEAD request as defined in RFC 2616.

7.6.3.6. The httpRequest Element Type (Obsolete)

The httpRequest element type specifies data for creating a HTTP request, such as media type, encoding, HTTP headers and HTTP body. The request URI for the HTTP request is the URI in xlink:href of the file element type.

The httpRequest element type has the following attribute types:

The method attribute type specifies the HTTP method; only the values “GET”, “POST”, “PUT” and “HEAD” are allowed. (Methods are case sensitive; “TRACE”, “OPTIONS”, “DELETE” and “CONNECT” are not useful in this context.)

The httpRequest element type contains the following element types, which occur in the following order:

The httpHeaders element type specifies headers for an HTTP request to a server. This element type has no attribute types and can contain only one element type:

The httpBody element type specifies content for the “body” or “payload” of an HTTP POST request.This element type has no attribute types and can contain only one element type:

The element types header and variable are empty element types with the following attribute types:

The name and value attribute types of both the header and body element types allow any character data (data type: xs:string).

8. Rules: The Element Types rules and rule

The rules element type contains the “rules” that are tested by a test case. “Rule” is here used as a generic term for accessibility requirements such as

The rules element type has no attribute types. It can only contain one element type:

The accessibility requirements identified by each of the rule elements have an AND relationship. This enables the creation of complex test cases where the impact of combinations of failures or techniques can be demonstrated.

8.1. The rule Element Type

There is one rule element per “rule” that is documented in the test case.

The rule element type has the following attribute types:

The xlink:href attribute type specifies the URI of the rule (data type xs:anyURI). The xlink:href attribute type does 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 xlink:href attribute type contains a URL with a fragment identifier: the URL part locates a “Rulesets XML” file, the fragment identifier refers to a rule ID which in turn references the relevant rule in an online source.

The primary attribute type specifies whether a rule is “primary” or not: primary rules are those against which the test case is supposed to be evaluated; other rules are informational. The default value of the primary attribute type is “yes”; in other words, all rule elements where the primary attribute is not explicitly set are treated as primary rules.

The rule element type contains the following element types, which occur in the following order:

8.1.1. The locations Element Type

The locations element type specifies the location or locations where relevant (especially faulty) code occurs, more specifically code that exhibits an issue (especially an error) relevant to the specified “rule”.

This element type has the following attribute type:

The expectedResult attribute type specifies the expected result of an evaluation of the code against the specified “rule” or a test procedure defined in a technique or failure. The following values are allowed: “pass”, “fail”, “cannotTell” and “notApplicable”. The value “cannotTell” is used if there is ambiguity or unclarity (for example, dependence on the implementation or version of a user agent or assistive technology, ambiguity in the accessibilty rules or in the specification of the file format). The value “notApplicable” can be used to point out explicitly that a specific location in the code is not relevant.

The locations element type can only contain one element type (and no character data):

The location element type specifies a location in the code. Sometimes a combination of features (markup, rules, etcetera) constitute an error when taken together (even if these features are not errors when considered separately). In that case, there should be one location element per feature/error. At least XPath or a combination of line and column number must be used.

Note: the current location pointers (line, column, xpath) in the location element type may eventually be replaced with the location pointers from EARL. (See also EARL Pointers in the mailing list archive of the TSD TF.) When EARL reaches W3C recommendation status, the current location pointers may be deprecated in favour of EARL Pointers.

The location element type has the following attribute types:

The techrefs attribute type specifies the techniques that are used at the location specified by the location attributes or the EARL location pointers. The list of (one or more) techniques is specified by means of a space-separated list if identifiers that match the id attributes of technique elements in the TCDL instance. This enables the specification of relationships between techniques and locations, in other words: what techniques or failures are exhibited at a specific location. For further details and an example, see the section Linking Locations and Techniques.

The xlink:href attribute type specifies the file in which the issue occurs. This attribute type must be used when the files element specifies more than one file; otherwise it can be omitted: if the files element contains only one file element, the file specified there is assumed to contain the issue.

The line and column attribute type specify the line and column, respectively, where the relevant code is located. These attribute types must always be used together. The value “1” denotes the first position.

The xpath attribute type specifies the location of an issue by means of an XPath expression as defined in XPath 2.0.

For extensibility, the location element type can contain any attribute and element types from in the EARL namespace.

The location element type can contain any combination of the following element types from the EARL namespace:

8.1.2. The techniques Element Type

The techniques element type specifies a list of techniques and/or failures demonstrated in the test case, especially WCAG 2.0 techniques and failures. The techniques element type contains the following element types:

The techniques element type is optional to allow the creation of test cases for which a technique or failure does not yet exist (in online documents).

Note. In the context of WCAG 2.0, a test sample should be a minimal piece of code that demonstrates a success criterion can be met or failed. Usually, this means that a test case maps to one and only one technique or failure. However, some WCAG 2.0 success criteria require a combination of techniques that collectively meet a success criterion, so it is sometimes necessary to point to a list of techniques by using more than one technique element.

8.1.2.1. The technique Element Type

The technique element type specifies a technique or a failure demonstrated in the test case, especially a WCAG 2.0 technique or failure.

The xlink:href attribute type points to a (WCAG 2.0) technique or failure. Since the WCAG 2.0 techniques will change in the future, dated URLs must be used. For example, to refer to failure F14 (Failure of SC 1.3.5 due to identifying content only by its shape or location) in the 27 April Working Draft of Techniques for WCAG 2.0, one must use the URL http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/#F14 (or http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#F14), not http://www.w3.org/TR/WCAG20-TECHS/#F14.

The id attribute type provides an indentifier for the technique. This enables the specification of relationships between locations (specified by location elements) and techniques: a location element can have a techrefs attribute pointing to techniques or failures listed in the techniques element. An example of this is provided below.

Note: for consistency, it is recommended to use the same identifier for the same technique throughout a test suite. For WCAG 2.0 techniques, it is possible to use the same identifiers as in Techniques for WCAG 2.0, so that automated scripts can check whether the identifiers match real techniques.

8.1.3. Linking Locations and Techniques

In TCDL, the specification of locations is required, but specifying techniques is optional. However, to express how a specific error location relates to a technique or failure listed in the techniques element, one can use ID-IDREFS references between location elements and technique elements. This is especially useful if a test cases uses several techniques in different locations.

Note: in the examples in this section, the namespace for XHTML (http://www.w3.org/1999/xhtml) is bound to the prefix 'h'.

Below is an example where the same technique is incorrectly implemented in two locations.

<!-- example 1 -->
<!-- This example is about a file with language changes and in which several instances of the lang attribute contain an illegal value (for example, "french" instead of "fr"). -->
<rule primary="yes" xlink:href="http://bentoweb.org/refs/rulesets.xml#WCAG2_20060427_3.1_meaning-other-lang-id">
  <locations expectedResult="fail">
    <location techrefs="H58">
      <earl:xPath>
        <earl:expression>/h:html/h:body/h:blockquote/h:p[4]/h:span[2]/h:span/@lang</earl:expression>
      </earl:xPath>
      <earl:lineCharLen>
        <earl:line>43</earl:line>
        <earl:char>15</earl:char>
      </earl:lineCharLen>
    </location>
    <location techrefs="H58">
      <earl:xPath>
        <earl:expression>/h:html/h:body/h:blockquote/h:p[6]/h:span[2]/h:span/@lang</earl:expression>
      </earl:xPath>
      <earl:lineCharLen>
        <earl:line>54</earl:line>
        <earl:char>26</earl:char>
      </earl:lineCharLen>
    </location>
  </locations>
  <techniques>
    <technique xlink:href="http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#H58"id="H58"/>
  </techniques>
  <techComment>
    <p>The test case is actually a failure (!) of the technique, because the language tag is not correct.</p>
  </techComment>
</rule>

Below is an example where a single location fails in two different ways.

<!-- example 2 -->
<!-- This example is about a file where an input field in a form launches a new window when the user enters text into it and where the context changes when the user removes focus from the input field. -->
<rule primary="yes" xlink:href="http://bentoweb.org/refs/rulesets.xml#WCAG2_20060427_3.2_consistent-behavior-no-extreme-changes-context">
  <locations expectedResult="fail">
    <location techrefs="F60 F9">
      <earl:xPath>
        <earl:expression>/h:html/h:body/h:form/h:p[2]/h:input[1]</earl:expression>
      </earl:xPath>
      <earl:lineCharLen>
        <earl:line>23</earl:line>
        <earl:char>6</earl:char>
      </earl:lineCharLen>
    </location>
  </locations>
  <techniques>
    <technique xlink:href="http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#F60"id="F60"/>
    <technique xlink:href="http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#F9"id="F9"/>
  </techniques>
</rule>

Below is an example where locations in multiple files are identified.

<!-- example 3 -->
<!-- This example is about the use of skiplinks to bypass a navigation menu that is repeated on multiple web pages. -->
<rule primary="yes" xlink:href="http://bentoweb.org/refs/rulesets.xml#WCAG2_20060427_2.4_navigation-mechanisms-title">
  <locations expectedResult="pass">
    <location xlink:href="../testfiles/sc2.4.1_l1_001.html techrefs="G1">
      <earl:xPath>
        <earl:expression>/h:html/h:body/h:div[@id='top']/h:a[@id='skipimg']</earl:expression>
      </earl:xPath>
      <earl:lineCharLen>
        <earl:line>19</earl:line>
        <earl:char>1</earl:char>
      </earl:lineCharLen>
    </location>
    <location xlink:href="../testfiles/sc2.4.1_l1_001_arts.html techrefs="G1">
      <earl:xPath>
        <earl:expression>/h:html/h:body/h:div[@id='top']/h:a[@id='skipimg']</earl:expression>
      </earl:xPath>
      <earl:lineCharLen>
        <earl:line>19</earl:line>
        <earl:char>1</earl:char>
      </earl:lineCharLen>
    </location>
    <!-- and so on for every other web page in the test case -->
  </locations>
  <techniques>
    <technique xlink:href="http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#G1"id="G1"/>
  </techniques>
</rule>

8.1.4. The functionalOutcome Element Type

The functionalOutcome element type specifies 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).

This element type has the following attribute types:

The functionalOutcome element type can only contain XHTML-style paragraphs.

8.1.5. The techComment Element Type

The techComment element type specifies a 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) that go beyond a mere description of the test case.

This element type has the following attribute types:

The techComment element can only contain XHTML-style paragraphs.

Below is an example of techComment from a BenToWeb test case that contains an object element with an image map (the object element contains another object element).

<!-- example 1 -->
<techComment>
  <p>The<html:code>img</html:code>element has an<html:code>alt</html:code>attribute.</p>
  <p>In Mozilla 1.7.3 and Firefox 1.0, the map does not work if the <html:code>map</html:code> element has only an <html:code>id</html:code> and no <html:code>name</html:code> attribute.</p>
  <p>Internet Explorer does not support <html:code>object</html:code> and does not display the fallback image if it is inside a nested object.</p>
</techComment>

8.2. Using rules: Examples

<!-- example 1 -->
<rules>
  <rule primary="yes"
      xlink:href="http://bentoweb.org/refs/rulesets.xml#WCAG2_20060427_3.1_meaning-doc-lang-id">
    <locations expectedResult="fail"/>
    <!-- other child elements omitted -->
  </rule>
</rules>

This rule means that the test case fails success criterion 3.1.1 (in the 27 April Working Draft of WCAG 2.0).

<!-- example 2 -->
<rules>
  <rule primary="yes"
      xlink:href="http://bentoweb.org/refs/rulesets.xml#WCAG2_20060427_1.1_text-equiv-all">
    <locations expectedResult="fail">
      <location xpath="/h:html/h:body/h:p[2]/h:img/@alt">
    </locations>
    <!-- other child elements omitted -->
  </rule>
  <rule primary="yes"
      xlink:href="http://bentoweb.org/refs/rulesets.xml#WCAG2_20060427_1.4_visual-audio-contrast-contrast">
    <locations expectedResult="fail">
      <location xpath="/h:html/h:body/h:p[2]/h:img">
    </locations>
    <!-- other child elements omitted -->
  </rule>
</rules>

Assuming that the image identified by the XPath statement /h:html/h:body/h:p[2]/h:img is a diagram with low contrast, this combination of rules means that the test case passes success criterion 1.1.1 (in the 27 April Working Draft of WCAG 2.0) because there is a text alternative that conveys the same information, but fails success criterion 1.4.1 because the luminosity contrast ratio between the diagram and its background is lower than 1:5. The XPath statements in the two rules clarify that both rules refer to the same image (assuming that there is more than one image in the sample file).

<!-- example 3 -->
<rules>
  <rule primary="yes"
      xlink:href="http://bentoweb.org/refs/rulesets.xml#WCAG2_20060427_4.1_ensure-compat-parses">
    <locations expectedResult="fail">
      <location xpath="/h:html/h:body/h:h2[1][@id='toc']"/>
      <location xpath="/h:html/h:body/h:h2[2][@id='toc']"/>
    </locations>
    <techniques>
      <technique xlink:href="http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/#F62"/>
      <-- Failure of SC 4.1.1 due to insufficient information in DOM to determine specific relationships in XML -->
    </techniques>
  </rule>
</rules>

Assuming that the code above comes from a description of an XHTML 1.1 file served as application/xhtml+xml, the above rule indicates that the file has an ambiguity in its Document Object Model (DOM) because there is a duplicate ID value.

<!-- example 4 -->
<rules>
  <rule primary="yes"
      xlink:href="http://bentoweb.org/refs/rulesets.xml#WCAG2_20060427_4.1_ensure-compat-parses">
    <locations expectedResult="fail">
      <location>
        <earl:xPath>
          <earl:expression rdf:datatype="http://www.w3.org/2001/XMLSchema#string">/h:html/h:body/h:h2[1][@id='toc']</earl:expression>
        </earl:xPath>
      </location>
      <location>
        <earl:xPath>
          <earl:expression rdf:datatype="http://www.w3.org/2001/XMLSchema#string">/h:html/h:body/h:h2[2][@id='toc']</earl:expression>
        </earl:xPath>
      </location>
    </locations>
    <techniques>
      <technique xlink:href="http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/#F62"/>
      <-- Failure of SC 4.1.1 due to insufficient information in DOM to determine specific relationships in XML -->
    </techniques>
  </rule>
</rules>

The example above is the same as the previous example, but with EARL pointers instead of attributes on the location element.

9. Namespace Mappings: The Element Types namespaceMappings and namespace

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.

The namespaceMappings element type contains the following element types:

The namespace element type has the following attribute types:

The nsPrefix attribute type specifies a namespace prefix; the nsURI attribute type specifies the corresponding namespace URI.

10. Other Content Models and Data Types

This section describes content models and data types that are used by several element types in TCDL.

10.1. XHTML-Style Inline Markup

This content model is a mixture of character data and the following XHTML elements:

The XHTML 1.0 specification allows that the above element types contain other element types. However, in TCDL the above element types must not contain element types other than those in the above list and the a element type (for links). Note that the schema for TCDL does not enforce this constraint.

10.2. XHTML-Style Paragraphs

This content model is a sequence of one or more p elements. The content model of these p elements is the XHTML-style inline markup described above.

10.3. The Attribute Types xml:lang and hrefLang

The xml:lang attribute type specifies the base language of an element’s attribute values and text content. The default value of this attribute is unknown. This attribute type is imported from the XML schema for XML 1.0, which is available at http://www.w3.org/2001/xml.xsd. The value of xml:lang is inherited; the data type is xs:language.

The hrefLang attribute type specifies the base language of the resource designated by the xlink:href attibute on the same element; its data type is xs:language.

10.4. The dir Attribute Type

The only values allowed for this attribute type are ltr (for left-to-right text) and rtl (for right-to-left text). When the attribute is not used, the text direction is left to right, unless another text direction is inherited from an ancestor element.

11. Extensibility of TCDL

Languages often evolve: certain features need to be refined, added or even removed because of new needs or to simplify the language. In a metadata format such as TCDL it is often useful to be able to add new elements and to be able to tell parsers that they can ignore elements and attributes they don’t know. Instead of allowing unknown elements anywhere in a TCDL file, the TCDL schema limits the addition of new elements to specific locations — the Extension element type and the extensibility points — so that new elements can only be added in a controlled way. This enables extensibility without descending into chaos.

The Extension element type can have any attribute types in any namespace; schema processors will attempt to find a schema document associated with the namespace and validate the attributes. If a schema processor cannot find the schema document or an attribute is invalid, it will raise errors (<xs:anyAttribute/>; with default attributes added, this results in <xs:anyAttribute namespace="##any" processContents="strict"/>).

The Extension element type contains at least one element type in the target namespace (http://bentoweb.org/refs/TCDL2.0/); schema processors will attempt to validate the elements for which they can find declarations (namely in the schema document associated with the namespace: the W3C XML schema for TCDL 2.0) and raise errors if they are invalid. Schema processors will not raise errors on elements for which they cannot find declarations (<xs:any namespace="##targetNamespace" processContents="lax" maxOccurs="unbounded"/>).

After the Extension element type, the W3C XML schema for TCDL 2.0 contains an extensibility point identified as <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>. This code specifies that only elements from namespaces other than the target namespace can be added after an Extension element, and that these elements must be in a namespace. Schema processors will attempt to validate the elements for which they can find declarations and raise errors if they are invalid. Schema processors will not raise errors on elements for which they cannot find declarations.

12. Rulesets

12.1. Introduction

The rules section of TCDL refers to accessibility requirements by means of URLs that end with a fragment identifier that corresponds to the ID of a “rule” in a “rulesets file”. A “rulesets file” is an XML file conforming to Rulesets XML 1.0.

Rulesets XML is an XML vocabulary for identifying and referencing accessibility checkpoints, success criteria or rules. A Rulesets XML serves as a global map of rulesets such as WCAG 1.0, WCAG 2.0, Section 508 and BITV and as a bridge between test case metadata (for example in TCDL 2.0) and those rulesets. An example ruleset, used in the BenToWeb project, is available at http://bentoweb.org/refs/rulesets.xml. Rulesets XML uses the namespace http://bentoweb.org/refs/rulesets; a W3C XML Schema is available at http://bentoweb.org/refs/schemas/rulesets.xsd.

12.2. Structure of Rulesets XML

The parts of a rulesets file are named after the constituent parts of WCAG 2.0 but should be sufficiently generic to be used for other rulesets.

Below is the skeleton of a Rulesets XML file.

<?xml version="1.0" encoding="UTF-8"?>
<rulesets xmlns="http://bentoweb.org/refs/rulesets"
  xmlns:xlink="http://www.w3.org/1999/xlink"
  xmlns:html="http://www.w3.org/1999/xhtml">
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  xsi:schemaLocation="http://www.w3.org/1999/xhtml http://www.w3.org/2004/07/xhtml/xhtml1-strict.xsd
    http://www.w3.org/1999/xlink http://bentoweb.org/refs/schemas/xlink.xsd
    http://bentoweb.org/refs/rulesets http://bentoweb.org/refs/schemas/rulesets.xsd">
  <!-- ruleset elements go here -->
</rulesets>

The root element type of a Rulesets XML file is rulesets. This element type has no attribute types and contains at least one instance of the ruleset element type.

12.2.1. The ruleset Element Type

A Rulesets XML document contains one or more rule sets (instances of the ruleset element type). Examples of rule sets are WCAG 1.0, WCAG 2.0, Section 508 and BITV. Working drafts of rulesets can also count as rule sets; for example, it is possible to treat the 30 June 2005 Working Draft of WCAG 2.0 as a different ruleset than the 23 November 2005 Working Draft of WCAG 2.0. All that is necessary is that each rulesets has a different and stable URL.

The ruleset element type has the following attribute types:

The ruleset element type contains the following element types:

12.2.2. The guideline Element Type

A ruleset consists of one or more subdivisions or “guidelines”: each ruleset element contains one or more guideline elements.

The guideline element type has the following attribute types:

The guideline element type contains the following element types:

Some “guidelines” have no further subdivisions (for example in Section 508), so successCriterion is not required.

12.2.3. The successCriterion Element Type

A “guideline” may consist of one or more subdivisions or “success criteria”: each guideline element can contain one or more successCriterion elements.

The successCriterion element type has the following attribute types:

Success criteria have no further subdivisions, so successCriterion is an empty element type.

12.3. Example: BenToWeb’s rulesets.xml

In BenToWeb’s rulesets.xml, a ruleset consists of guidelines, and a guideline may consist of success criteria. Depending on the ruleset, guidelines and success criteria refer to:

The value of the name attribute of a guideline element corresponds to

The id attribute type of the guideline element type is required; the name attribyte type cannot serve this purpose because IDs must not start with a number.

For each guideline, all success criteria or checkpoints are listed as successCriterion elements. The value of the name attribute of a successCriterion element corresponds to

The level attribute type is optional except for WCAG 2.0.

Appendix A: W3C XML Schema for TCDL 2.0

@@todo add XML Schema.

The schema is available at http://bentoweb.org/refs/schemas/tcdl2.0.xsd.

Appendix B: TCDL Examples

A Minimal TCDL File

The example below uses only required element and attribute types, except the optional xlink:href attribute on the file element.

<?xml version="1.0" encoding="UTF-8"?>
<testCaseDescription id="wcag20060427_sc3.1.1_l1_001"
  xml:lang="en"
  xmlns="http://bentoweb.org/refs/TCDL2.0/"
  xmlns:btw="http://bentoweb.org/refs/TCDL2.0/"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:xlink="http://www.w3.org/1999/xlink"
  xmlns:html="http://www.w3.org/1999/xhtml"
  xmlns:earl="http://www.w3.org/WAI/ER/EARL/nmg-strawman#"
xsi:schemaLocation="http://bentoweb.org/refs/TCDL2.0/ http://bentoweb.org/refs/schemas/tcdl2.0.xsd
    http://purl.org/dc/elements/1.1/ http://dublincore.org/schemas/xmls/qdc/2006/01/06/dc.xsd
    http://www.w3.org/1999/xhtml http://www.w3.org/2004/07/xhtml/xhtml1-strict.xsd
    http://www.w3.org/1999/xlink http://bentoweb.org/refs/schemas/xlink.xsd
    http://www.w3.org/2006/http# http://bentoweb.org/refs/schemas/http.xsd
    http://www.w3.org/WAI/ER/EARL/nmg-strawman# http://bentoweb.org/refs/schemas/earlwd.xsd"
  >
  <formalMetadata>
    <title>German text with English language identification</title>
    <dc:creator>John.Doe@example.com</dc:creator>
    <dc:language>en</dc:language>
    <dc:rights>Copyright Example.com</dc:rights>
    <dc:date xsi:type="btw:btwDate">2006-08-31</dc:date>
    <status>new</status>
    <version>$Revision$</version>
  </formalMetadata>
  <technologies>
    <technicalSpec><!-- xlink:href is optional -->
      <specName>
         <html:acronym>XHTML</html:acronym>&#8482; 1.0: The Extensible HyperText Markup Language (Second Edition)
      </specName>
    </technicalSpec>
  </technologies>
  <testCase>
    <dc:description xsi:type="btw:dcHtmlInline">Web page with an excerpt of Peter Handke's play<html:span lang="de">Publikumsbeschimpfung</html:span>(in German); the<html:code>html</html:code>element has a<html:code>lang</html:code>attribute with the value "en" (for English) instead of "de" (for German).
    </dc:description>
    <purpose><p>This test case is intended to fail because the language of the page is not correctly identified.</p>
    </purpose>
    <requiredTests>
      <testModes>
        <testMode>oneExpert</testMode>
      </testModes>
    </requiredTests>
    <files>
    <file xlink:href="wcag20060427_sc3.1.1_l1_001.html"/>
    <!-- Note: xlink:href is actually optional -->
    </files>
  </testCase>
  <rules>
    <rule primary="yes"
        xlink:href="http://bentoweb.org/refs/rulesets.xml#WCAG2_20060427_3.1_meaning-doc-lang-id">
      <locations expectedResult="fail"/>
    </rule>
  </rules>
</testCaseDescription>

TCDL File with EARL Location Pointers and HTTP in RDF

See http://bentoweb.org/refs/TCDL2.0/sc3.1.1_l1_001.xml.

A TCDL Template

See http://bentoweb.org/refs/TCDL2.0/scx.x.x_lx_xxx.xml.

Appendix C: W3C XML Schema for Rulesets

The schema is available at http://bentoweb.org/refs/schemas/rulesets.xsd.

Appendix D: Relation with Other W3C Technical Documents and Submissions

Test Case Description Language 1.0 – Submission to QA Working Group 12 October 2003

On 12 October 2003, the Quality Assurance Working Group (QA WG) published the submission Test Case Description Language 1.0. Many sections of this document are unfinished; according to a message of Lofton Henderson to the QA WG mailing list, this version was going to be superseded.

@@todo describe differences between the two TCDLs.

Test Metadata – W3C Working Group Note 14 September 2005

On 14 September 2005, the Quality Assurance Working Group (QA WG) published a Working Group Note on Test Metadata. (See also Testcase Metadata, draft, 9 September 2005.)

The W3C Working Group Note “Test Metadata” (14 September 2005) suggests fourteen metadata elements for test suites. The table below shows how these metadata elements map to TCDL elements. (In this table, TCDL elements are identified by means of XPath expressions without a namespace prefix and with the root element — testCaseDescription — omitted, except for the attributes of that element.)

Mapping of W3C Test Metadata to TCDL
W3C Metadata TCDL Comment
Identifier testCaseDescription/@id
Title formalMetadata/title In TCDL, titles are not necessarily unique; they don’t duplicate the identifier.
Purpose testCase/purpose
Description testCase/dc:description In TCDL, the description should help the reviewer understand how the test materials are constructed and the behaviour when a user interacts with it.
Status formalMetadata/status
SpecRef rules/rule/@xlink:href,
rules/rule/techniques/technique
and
technology/technicalSpec		 In TCDL, two types of specifications need to be referenced: the accessibility guidelines (“rules”)—optionally supplemented with techniques—and the specifications of the technologies in the test.
Preconditions testCase/preconditions Not used in BenToWeb, because test cases map directly to WCAG success criteria instead of tests.
Inputs testCase/files/file/http:GetRequest, testCase/files/file/http:PostRequest, testCase/files/file/http:PutRequest, testCase/files/file/http:HeadRequest Only for the special case where it is necessary to (re)create a specific HTTP request.
ExpectedResults rules/rule/locations/@expectedResult
and
rules/rule/functionalOutcome
Version formalMetadata/version It may be possible to rely on a version control system instead. If version information is maintained in TCDL it is possible to update it manually or to rely on the CVS keyword $Revision$.
Contributor formalMetadata/dc:contributor
Rights formalMetadata/dc:rights
and
formalMetadata/source/dc:rights		 TCDL can document rights related to a test case and rights related to borrowed materials.
Grouping - (Because TCDL describes only single test cases, grouping should happen at a higher level.)
SeeAlso technology/technicalSpec
(and
rules/rule/techComment)

Appendix E: References

About Baselines and WCAG 2.0
David MacDonald, John Slatin, Gregg Vanderheiden, eds. About Baselines and WCAG 2.0. Version 1.0.
BCP 47
H. Alvestrand, ed. Tags for the Identification of Languages. IETF. Best Current Practice (BCP) 47. January 2001.
Conformance Test Process For WCAG 2.0
Chris Ridpath, Jenae Andershonis, eds. Conformance Test Process For WCAG 2.0. W3C Working Draft 2005-02-23.
DCMES 1.1
Dublin Core Metadata Element Set, Version 1.1: Reference Description. DCMI Recommendation 20 December 2004.
EARL
Charles McCathieNevile, Shadi Abou-Zahra, eds. Evaluation and Report Language (EARL) 1.0 Schema. W3C Working Draft 27 September 2005.
HTTP Vocabulary in RDF (2006)
Johannes Koch, Carlos A Velasco, Shadi Abou-Zahra, eds. HTTP Vocabulary in RDF. W3C Working Draft 20 December 2006.
HTTP Vocabulary in RDF
Johannes Koch, Carlos A Velasco, Shadi Abou-Zahra, eds. HTTP Vocabulary in RDF. W3C Editor’s Draft 01 March 2007.
HTTP Vocabulary in RDF
Johannes Koch, Carlos A Velasco, Shadi Abou-Zahra, eds. HTTP Vocabulary in RDF. W3C Working Draft 23 March 2007.
IANA
Internet Assigned Numbers Authority (IANA). MIME Media Types.
ICF
World Health Organization (WHO). International Classification of Functioning, Disability and Health.
ISO 8601
ISO (International Organization for Standardization). Representations of dates and times, 1988-06-15.
Orchard 2003
David Orchard. Versioning XML Vocabularies. XML.com, 3 December 2003.
Orchard 2004
David Orchard. Extensibility, XML Vocabularies, and XML Schema. XML.com, 27 October 2004.
RFC 2119
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. IETF. Request for Comments 2119. BCP 14 March 1997.
RFC 2396
T. Berners-Lee, R. Fielding, L. Masinter. Uniform Resource Identifiers (URI): Generic Syntax. IETF. Request for Comments 2396. August 1998.
RFC 2616
R. Fielding, J. Gettys, J. Mogul, H. Frystyk Nielsen, L. Masinter, P. Leach and T. Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1. IETF. Request for Comments 2616. June 1999.
RFC 3066
H. Alvestrand, ed. Tags for the Identification of Languages. IETF. Request for Comments 3066. 1995.
RFC 3986
T. Berners-Lee, R. Fielding, L. Masinter. Uniform Resource Identifier (URI): Generic Syntax. IETF. Request for Comments 3986. January 2005.
Techniques for WCAG 2.0
Ben Caldwell, Wendy Chisholm, John Slatin, and Gregg Vanderheiden, eds. Techniques for WCAG 2.0. W3C Working Draft 27 April 2006.
Usability First™ Usability Glossary
Usability Glossary. Usability First.
W3C QA Framework Primer
Lofton Henderson, Lynne Rosenthal, Mark Skall. QA Framework Primer. W3C Quality Assurance Activity. Last modified 24 August 2005.
W3C QA Voc
Quality Assurance glossary. W3C Quality Assurance Activity.
WCAG 2.0
Ben Caldwell, Wendy Chisholm, John Slatin, and Gregg Vanderheiden, eds. Web Content Accessibility Guidelines 2.0. W3C Last Call Working Draft 27 April 2006.
XLink 1.0
Steve DeRose, Eve Maler, David Orchard, eds. XML Linking Language (XLink) Version 1.0. W3C Recommendation 27 June 2001.
XML 1.0
Tim Bray, Jean Paoli, C. M. Sperber-McQueen, Eve Maler, François Yergeau, eds. Extensible Markup Language (XML) 1.0 (Third Edition). W3C Recommendation 04 February 2004.
XML Schema Part 2: Datatypes
Paul V. Biron, Ashok Malhotra, eds. XML Schema Part 2: Datatypes Second Edition. W3C Recommendation 28 October 2004.
XPath 1.0
James Clark, Steve DeRose, eds. XML Path Language (XPath) Version 1.0. W3C Recommendation 16 November 1999.
XPath 2.0
Anders Berglund, Scott Boag, Don Chamberlin, Mary F. Fernández, Michael Kay, Jonathan Roby, Jérôme Siméon, eds. XML Path Language (XPath) Version 2.0. W3C Recommendation 23 January 2007.

Appendix F: Acknowledgements

This work has been undertaken in the framework of the project BenToWeb — IST-2-004275-STP — funded by the IST Programme of the European Commission.