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

RE: TCDL Draft E (second response)

From: Carlos Iglesias <carlos.iglesias@fundacionctic.org>
Date: Thu, 14 Sep 2006 15:18:25 +0200
Message-ID: <09700B613C4DD84FA9F2FEA521882819015659A3@ayalga.fundacionctic.org>
To: "Shadi Abou-Zahra" <shadi@w3.org>, "Christophe Strobbe" <christophe.strobbe@esat.kuleuven.be>
Cc: "TSDTF" <public-wai-ert-tsdtf@w3.org>


 Hi group,
Comments below...

> >> A. DC elements are frequently used, why did you create "date" and 
> >> "description" attributes instead adopting "dc:date" and 
> >> "dc:description"?
> > 
> > I have added notes about the limiting data types of dc:date and 
> > dc:description (in both cases xs:string) to the spec.
> 
> I think this is a better approach.

Works for me too

> >> 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 case.
> > 
> > How about reusing or adapting the list from the Conformance Test 
> > Process For WCAG 2.0 
> > (http://www.w3.org/WAI/GL/WCAG20/tests/ctprocess.html)?
> > Chris, do you have any objections?
> > The list of values is
> > - unconfirmed,
> > - new,
> > - assigned,
> > - pending,
> > - accepted,
> > - rejected,
> > - holding.
> > For explanations, see the URL above.
> 
> I agree with this proposal, the list seems complete.

It's OK for me too. 
 
> >> 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?
> 
> This is one of the things that is convincing me to keep the 
> techComment element (see the other thread of comments).

Examples about the use would be useful too in this case.

> >> 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.
> 
> Is this definition of a "baseline with exceptions" really 
> inline with WCAG 2.0?

I agree in the fact that there are problems with the current definition of baseline within WCAG2, as the ERT group discussed [1] and reported [2] in the past, but I think it's obvious that we should adopt WCAG2 definition in this group. Maybe our further work will provide valuable feedback for the WCAG WG on this subject.
 
> >> 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?
> 
> I vote for removing it because I don't see a use case for it 
> in the context of this Task Force. I am happy to hear otherwise...

Dead to the 'requiredTests' then!!!!
Ahem! I mean +1 for removing it ;oD


[1] - [http://www.w3.org/2006/05/17-er-minutes#item02]
[2] - [http://lists.w3.org/Archives/Public/public-wai-ert/2006May/0066.html]


Regards,
 CI.
 
--------------------------------------

Carlos Iglesias

CTIC Foundation
Science and Technology Park of Gijón
33203 - Gijón, Asturias, Spain 

phone: +34 984291212
fax: +34 984390612
email: carlos.iglesias@fundacionctic.org
URL: http://www.fundacionctic.org
Received on Thursday, 14 September 2006 13:18:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:33 GMT