Test Case Description Language

The Global Structure of a TCDL File [stable]

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

• id: an identifier for the test case that is unique that is unambiguous and unique withing the context of the test case (the context can be a test suite);
• xml:lang: the default language of the TCDL file [@@todo crossreference];
• dir: the default text direction of the TCDL file [@@todo crossreference];
• xmlns="http://bentoweb.org/refs/TCDL2.0": the default namespace;
• xmlns:dc="http://purl.org/dc/elements/1.1/": namespace for Dublin Core Element Set;
• xmlns:xlink="http://www.w3.org/1999/xlink": namespace for W3C XLink;
• xmlns:html="http://www.w3.org/1999/xhtml": namespace for XHTML 1.x;
• xmlns:xsd="http://www.w3.org/2001/XMLSchema";
• xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
• xsi:schemaLocation: for linking namespace URIs with the URIs of the corresponding schema documents.

Note: the namespace prefixes need not be the same as those in the above list.

Note: for extensibility, the testCaseDescription element type can have any other attribute types in the same namespace. [@@check that <xs:anyAttribute/> means only attributes in same namespace; <xs:anyAttribute namespace="##any" /> means in any namespace and is the default.]

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

• formal metadata (the formalMetadata element type, required),
• technologies (the technologies element type, required),
• test case (the testCase element type, required),
• rules (the rules element type, required),
• namespace mappings (the namespaceMappings element type, optional),
• an optional extension element (Extension),
• an extensibility point (any other element types in any namespace).

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/TCDL1.1"
  xmlns:xsd="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"
  xsi:schemaLocation="http://bentoweb.org/refs/TCDL1 http://bentoweb.org/refs/schemas/tcdl1.xsd
    http://bentoweb.org/refs/TCDL1.1 http://bentoweb.org/refs/schemas/tcdl1.1.xsd
    http://purl.org/dc/elements/1.1/ http://dublincore.org/schemas/xmls/simpledc20021212.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"
  >
  <formalMetadata>
    <!-- child elements omitted -->
  </formalMetadata>
  <technology>
    <!-- child elements omitted -->
  </technology>
  <testCase complexity="atomic">
    <!-- 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.

Formal Metadata: The formalMetadata Element Type [stable]

The formalMetadata element type contains formal or administative metadata.

This element type has the following attributes:

• xml:lang (optional),
• dir (optional).

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

• title (required),
• dc:creator (required),
• dc:language (required),
• dc:rights (required),
• date (required),
• status (required),
• version (optional),
• source (optional),
• dc:contributor (optional),
• Extension (optional extension element),
• any other element types in any namespace (extensibility point).

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 attributes:

• xml:lang (optional),
• dir (optional).

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

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 attributes.

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

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 attributes.

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 ISO 3066. (@@todo check ISO 3066 or successor). The value must not be empty or null.

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 attributes.

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

The date Element Type

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

This element type has no attributes.

The date element type has the data type xs:date (which is inspired by ISO 8601). Example: 2004-10-01 means 1 October 2004.

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 attributes.

The status element type has the data type xs:string, but the values should really be chose 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.

The version Element Type

The version element type contains an identifier that allows one to distinguish between different revisions of a test case.

This element type has no attributes.

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

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 attributes:

• xml:lang (optional),
• dir (optional).

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

• testSuite (required),
• sourceFile (required and repeatable),
• dc:rights (optional),
• comment (optional).

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:

• xlink:href (required) to specify the location of the test suite.

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

• name (required) to specify the name of the test suite.

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

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 attributes:

• changed (required) to specify whether the file was borrowed with changes (“true”) or without any changes (“false”),
• xlink:href (required) to specify the location of the original file.

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

• dc:creator (required).

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

The dc:rights Element Type

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

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.

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 attributes.

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

Technologies: The technologies Element Type [stable]

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

• the formal specification or recommendation that defines the technology (by name and URL; required);
• the technology features (for example, which XHTML elements and/or attributes) that are relevant to the test case (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 case (optional).

This element type has the following attributes:

• xml:lang (optional),
• dir (optional).

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

The technicalSpec Element Type

The technicalSpec element type identifies the file format (proprietary, W3C recommendation or other type of technical specification) of 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. There is one technicalSpec element for each file format used by the test case.

This element type has the following attributes:

• xlink:href (required),
• baseline (optional).

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

The baseline attribute type specifies whether something 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 (W3C Working Draft 27 April 2006) and About Baselines and WCAG 2.0.) [@@References]

The technicalSpec element type can contain two other element types:

• specName (required),
• testElements (optional).

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.

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, …). This element type has no attributes. It contains at least one instance of the testElement element type.

The testElement element type contains a description of a specific element or feature. There is one testElement for each feature. For CSS, the name of the rule, selector, property, property value, … can be provided. For proprietary elements and attributes (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:

• xml:lang (optional),
• dir (optional),
• localname (required),
• namespace (optional).

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:

• xml:lang (optional),
• dir (optional),
• xlink:href (required).

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

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:

• xml:lang (optional),
• dir (optional).

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

Test Case: The testCase Element Type [stable, except last few sections]

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 checkpoint (WCAG 1.0) or success criterion (WCAG 2.0), or complex if it applies to multiple checkpoints or success criteria. [@@more general formulation?]

The testCase element type can contain five other element types:

• description (required),
• purpose (required),
• preconditions (optional),
• requiredTests (required),
• files (required).

The description Element Type

The 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:

• xml:lang (optional),
• dir (optional).

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

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. [@@reword:] It does not need to repeat the rule or success criterion. (Strictly speaking, this goes beyond the Purpose in W3C Working Group Note on Test Metadata.)

This element type has the following attribute types:

• xml:lang (optional),
• dir (optional).

This element type can only contain XHTML-style paragraphs.

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 (##any).

The requiredTests Element Type

The requiredTests element type describes

• the test mode or modes (required): the ways in which the test case should be evaluated to advance the test case from “draft” status to “accepted”;
• one or more test scenarios for end user evalution (strictly optional, but required if the test mode is “end user”): a scenario consists of
  • user guidance (for example, advice on features of a user agent that should be supported by and enabled in a browser),
  • questions that the user is expected to answer (yes/no question, open question, Likert scale, multiple choice, or a combination of yes/no and open question),
  • the experience that the user should have with certain user agents or assistive technologies to evaluate the test, and
  • optionally, disabilities to which the test is relevant.

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 attributes for the requiredTests element type but allows the use of any attributes for extensibility.

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

• testMode (required),
• scenario (optional and repeatable),
• Extension (optional extension element),
• any other element types in any namespace (extensibility point).

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 attributes and allows only string values (xs:string).

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:

• id (required) for an identifier that is unique within the TCDL file.

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

• dc:creator (optional),
• date (optional),
• status (optional),
• scenarioNotes (optional),
• userGuidance (optional and repeatable, one per language),
• questions (required),
• experience (required),
• disabilities (optional).

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

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:

• xml:lang (optional),
• dir (optional).

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

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:

• xml:lang (required),
• dir (optional).

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.

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. There should be one question or set of questions per language represented in the evaluation panel.

This element type has the following attribute types:

• xml:lang (required),
• dir (optional).

The questions element type can contain only one of the following five element types, but in as many language versions as are needed:

• openQuestion (optional, repeatable),
• yesNoQuestion (optional, repeatable),
• yesNoOpenQuestion (optional, repeatable),
• likertScale (optional, repeatable),
• multipleChoice (optional, repeatable).

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:

• xml:lang (optional),
• dir (optional).

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

• questionText (required, repeatable), which contains the actual question, and
• space (required) which specifies the size of the text area in which the user can enter a response.

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.

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:

• xml:lang (optional),
• dir (optional).

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

• questionText (required, repeatable), which contains the actual question, and
• optionYes (required),
• optionNo (required),
• optionOther (optional).

The questionText element type is defined above.

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

• value (required) for the value that will be sent to the server if the user selects this option,
• expected (optional) to specify if this option is what the question author would expect from the user (indicated with the values “yes” or “no”),
• xml:lang (optional),
• dir (optional).

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:

• expected (optional) to specify if this option is what the question author would expect from the user (indicated with the values “yes” or “no”),
• xml:lang (required),
• dir (optional).

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:

• questionText (required, repeatable), which contains the question for the yes-no part and possibly also for the open part,
• optionYes (required),
• optionNo (required),
• optionOther (optional),
• questionText (optional, repeatable), which contains the question for the open part if this is not already contained in the first questionText(s),
• space (required), which specifies the size of the text area in which the user can enter a response.

@@todo add details or references to previous sections.

The likertScale Element Type

The likertScale element type specifies a Likert scale, which is a type of survey question where respondents are asked to rate the level at which they agree or disagree with a given statement.

This element type has the following attribute type:

• display (required), which defines how a list of choices is displayed: vertically, horizontally or as a drop-down list (with the values “vertical”, “horizontal” and “dropdown”, respectively).

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:

• questionText (required, repeatable), which contains the actual question, and
• likertLevel (required, exactly five times).

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.

@@todo add details.

The experience Element Type

@@A user's level of experience with the specified technologies. There are three categories of technologies: assistive technologies, user agents and devices. User agent also covers browser plugins.

The disabilities Element Type

@@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 files Element Type

The files element type contains information about each of the test files that are relevant to the rule or success criterion:

• the URL of the test file (optional),
• the language of the test file (optional),
• data to create an HTTP request (optional): media type, encoding, HTTP headers and HTTP body.

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. (@@add: only "Web units".)

Namespace Mappings: The Element Types namespaceMappings and namespace [stable]

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 namespace1 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.

Other Content Models and Data Types [stable]

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

XHTML-Style Inline Markup

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

• em (emphasis);
• strong (strong emphasis);
• dfn (defining instance of a term or phrase);
• code (program code);
• q (inlined quote);
• samp (sample);
• kbd (keyboard input, something a user would input);
• var (variable);
• cite (citation);
• abbr (abbreviation);
• acronym;
• sub (subscript);
• sup (superscript);
• br (forced line break);
• span (generic container);
• bdo (I18N bidirectionality override).

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.

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.

The Attribute Types xml:lang and hrefLang

@@todo xml:lang

The hrefLang attribute type has the data type xs:language. @@todo see http://www.w3.org/TR/1999/REC-html401-19991224/struct/links.html#adef-hreflang.

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.