W3C home > Mailing lists > Public > public-wai-ert-tsdtf@w3.org > September 2006

RE: TCDL Draft E (second response)

From: Christophe Strobbe <christophe.strobbe@esat.kuleuven.be>
Date: Tue, 12 Sep 2006 20:46:11 +0200
Message-Id: <>
To: TSDTF <public-wai-ert-tsdtf@w3.org>

Hi Carlos, All,

I'm taking a second pass at a response, with more details and
with changes to the spec.

At 13:08 12/09/2006, Carlos Iglesias wrote:
>Another couple of comments for further discussion (apologies for the
>late sending):
>A. DC elements are frequently used, why did you create "date" and
>"description" attributes instead adopting "dc:date" and

I have added notes about the limiting data types of dc:date and
dc:description (in both cases xs:string) to the spec.

>B. in "formalMetadata" "status" is intended to provide a value from an
>enumerated list, we should consider providing also a "pointer" to the
>"allowable values" or just provide a list of them for our specific use

How about reusing or adapting the list from the Conformance Test
Process For WCAG 2.0
Chris, do you have any objections?
The list of values is
- unconfirmed,
- new,
- assigned,
- pending,
- accepted,
- rejected,
- holding.
For explanations, see the URL above.

>C. In "technologies" "xlink:href" is optional in the attached example
>but required in the spec draft, what's the intended value?

Thanks for catching this. xlink:href is meant to be optional except on
sourceFile (which we are probably dropping because it is part of
source). I have corrected the spec.
Would it be necessary to add guidance on what to put in xlink:href?

>D. If we reference browser vendor documents as "technologies", should we
>create a test case for each browser vendor (i.e Javascript)?

I thought we'd rather avoid that. The browser vendor documents
sometimes describe features that have been widely adopted, for
example the controversial embed element, but there is no neutral
and stable spec that describes them.
Any comments or suggestions?

>E. In "technologies", baseline attributes in "technicalSpec" and
>"testElement" are potentially in conflict, we should consider dropping
>one of both. Additionally, how are we going to manage baselines? Is
>expected that the group will create test cases for all posible
>combinations of baselines?

The problem with defining "baseline" on the level of technologies only
is that it is a simple binary representation that does
not do justice to the reality of incomplete implementations by
user agents. Some websites that put HTML 4.01 in their baseline will
assume that every feature is supported, while others will assume that
object, link, longdesc, etc are not adequately supported by the user
agents of a significant percentage of their visitors. [These are not
the best examples but I hopeh they clarify my point.] This means that
some websites will use fall-back techniques such as 'embed', while others
will not.
That's why it is possible to say that technology X is in the baseline
of a test case but element Y is not.

(I also wonder if "baseline" can handle modules in modularized specs
such as XHTML 1.1.)
Perhaps I should draw part of an earlier explanation about baselines
into the spec.

>F. In "testCase" I think that the expected results are important enough
>to deserve their own element, we should consider separating the
>"purpose" and the expected results (maybe "postconditions"?)

Expected results are important, obviously, but using an attribute works
very well in BenToWeb.
A separate 'postconditions' element would risk duplicating other
information from 'description', 'purpose' and/or 'functionalOutcome'
depending on what you want to put in 'postconditions'.

>G. In "testCase" the "requiredTests" element faces complex problems,
>like user testing or accessibility problems and disabilities matching,
>that need further work and consensus. I think it's out of the scope of
>this group because there is no common criterion (AFAIK there's no WCAG
>WG work on the subject), some of the properties could be useful during
>the development, but should not be published in the final version.

We didn't get this far in the call.
In 'testCase', 'description', 'purpose' and 'files' should stay, in
my opinion. 'requiredTests' can be removed if the rest of the task force
thinks it should be removed. Any comments?

>H. There is no much information about "rules" but I'm wondering whether
>relevant locations within the test file are necessary and if we need
>outcome information (pass or fail). IMO the whole test case is relevant
>or irrelevant, and if a rule is intended to pass a test case and other
>rule is intended to fail the same test case they are not compatible, so
>they need different test cases.

* Can you explain why we would not need outcome information? I thought we
wanted to note somewhere if a test case passes or fails an SC; that
seems an essential part of our metadata.

* The locations tell humans and tools where an issue is located;
using it is optional. I see no important reason to remove it.

* It is possible to list more than one rule, so that you can say, for
example, that a test case passes SC 1.1.1 (text alternative) but not
SC 2.3.1 (flash threshold) (or another, more interesting combination
of SCs). It can even be used to say that a test cases passes SC x.y.z
in the current draft but that it did not pass the corresponding SC
in an earlier draft (e.g. after we update the test suite to a new
WCAG draft, which is what we are doing in BenToWeb).
I assume that in practice, we'll map each test case to just one "rule",
By the way, a rule does not pass a test case: it is the other way around.

Best regards,


Christophe Strobbe
K.U.Leuven - Departement of Electrical Engineering - Research Group on 
Document Architectures
Kasteelpark Arenberg 10 - 3001 Leuven-Heverlee - BELGIUM
tel: +32 16 32 85 51

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Received on Tuesday, 12 September 2006 18:46:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:00 UTC