- From: Carlos Iglesias <carlos.iglesias@fundacionctic.org>
- Date: Thu, 14 Sep 2006 15:18:25 +0200
- 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 UTC