RE: sc2.5.1_l1_003 step 2: Structure review

Hi Carlos,

Quoting Carlos Iglesias <carlos.iglesias@fundacionctic.org>:
> > Thanks for completing your action items! I think you've shown 
> > a couple of inconsistencies and issues with the checklists 
> > that we need to discuss on the teleconference and update.
> > 
> > Do you have other observations or ideas from carrying out 
> > these reviews?
> 
> Some random thoughts:
> 
> - There is a technology dependency (JS) in the sc2.5.1_l1_002 test
> sample. In this case the related technique is specifically about
> client-side validation, so it's quite obvious we should need
> client-side technology, but do we need to explicitly say it in the
> metadata? (the baseline again) 

This refers to sc2.5.1_l1_002. In this test case, JavaScript is 
explicitly excluded in the baseline by means of the second 
"technicalSpec" element in "technologies".


> - Right now I still don't get the whole ruleset thing for the
> objectives of this TF. In the uploaded test cases the rule elements
> point to an xml document with a series of rulesets. I think we should
> think about restricting these pointers to direct WCAG2 references.

The rulesets XML document was created because not all accessibility 
requirements documents (or at least their normative versions) are in a 
format that allows pointers into the document (like HTML's fragment 
identifiers). The rulesets XML provides an ID for each accessibility 
requirement. It's a kind of adapter or bridge between our metadata and 
the actual accessibility documents. (If the accessibility document 
should move to another address, you only need to update the rulesets 
XML instead of hundreds of test cases.)
Of course, WCAG 2.0 is a special case because W3C/cool URLs don't 
change and WCAG 2.0 contains many fragment identifiers.


> - I'm not sure about how minimal should the test samples be, I mean
> the sc2.5.1_l1_002 test sample is compound just of a label and an
> input, it's minimal and complete from the point of view of automatic
> validation, but it doesn't look complete at all from an user
> perspective.

We may need to discuss that in the next telecon.


> (...)
> 
> > Do you have 
> > ideas for improving the process and reducing the effort 
> > needed for reviews?
> 
> IMO trying to scrutinize the XML directly is quite a rough work. It
> may help if we provide a web interface to see the metadata. 

It becomes easier when you get more familiar with the format but I 
agree that we will benefit from a web interface.

> Obviously as much automatic verification as we can do 
> will also be helpful.
> 
> Step 3 is a more light process but I think it could also be lightly
> facilitated if the links to relevant techniques and test procedures
> are directly provided (instead of having to scrutinize inside the XML
> again)

The scripts that generate the web interface can take care of that; it's 
a matter of parsing both the TCDL and the rulesets XML (quite feasible 
with XSLT).

Best regards,

Christophe

-- 
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
http://www.docarch.be/ 

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Received on Tuesday, 2 January 2007 14:17:59 UTC