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

Re: Formalizing WCAG 2.0 test procedures

From: Vicente Luque Centeno <vlc@it.uc3m.es>
Date: Wed, 6 Dec 2006 17:51:21 +0100 (CET)
To: Shadi Abou-Zahra <shadi@w3.org>
cc: public-wai-ert@w3.org
Message-ID: <Pine.LNX.4.61.0612061717180.28523@violin.it.uc3m.es>

On Wed, 6 Dec 2006, Shadi Abou-Zahra wrote:

> Hi Vicente,
> Vicente Luque Centeno wrote:
>> For instance, at 
>> http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#H37
> Remember that this is still a draft document. The particular technique you 
> are referring to (H37) seems to be incomplete and a test procedure is still 
> not provided. If you look at the next one below (H39), you will find an 
> example of how a complete test procedure could look like.

It is strange that a test procedure for images' alt attribute is still not 
provided. The procedure for the one below (H39) is not automatable with a 
reasonable degree of trust. For instance, step 1 says something difficult 
to determine by a program:

Check for layout tables: determine whether the content has a relationship 
with other content in both its column and its row

    1. If ?no," the table is a layout table.
    2. If ?yes," the table is a data table.

That kind of "relationship" concept is difficult to implement. :-(

>> Maybe I didn't search well, ... is there any attempt to provide evaluation 
>> tests procedures (beyond sample tests)? Or is it still a "for-the-future" 
>> work? Maybe I didn't look at the appropriate pages? As you already know, I 
>> would really be happy to collaborate with that. :-)
> See the above. You were looking at the right document but at an incomplete 
> section thereof.

I guess this will be challenged in a future.

>> but it's better if comes with a rule saying that the following template 
>> will never instanciate.
> Most would probably agree that the test procedure must be unambiguous. For 
> example "every IMG element must have an ALT attribute" could be such a 
> testable statement. However, in the past there has been no consensus on 
> providing such statements in XSLT. The primary reasons were that XSLT has 
> significant limitation for other types of statements (for example regarding 
> the content of the ALT attribute etc), that XSLT is less easy to read by 
> day-to-day Web developers, and that there is no particular reason for 
> preferring XSLT over another language. However, I do recall some discussion 
> about using pseudo code (as the MWI folks did) in the test procedures but am 
> not sure how WCAG WG will decide on this.

I am aware that people from WCAG WG has little knowledge on XSLT 
expressivity, so I would argue for pproviding expressions not only on 
XSLT, but also with equivalents in XQuery, Pseudo code (and maybe 
Schematron as well). Both XSLT and XQuery are W3C recommendations.

So, my conclusion is:

1.- Pseudo code is not appropriate for differentiating automatable from 
non-automatable tests (see the examples H39 and H37 above).

2.- XSLT or XQuery or Schematron are not easy-to-read by usual Web 

3.- Combining Pseudo code + (XSLT and/or XQuery and/or Schematron) could 
make the specification "easy to read" as well as "easy to implement". In 
fact, providing a formalized rule in (XSLT and/or XQuery and/or 
Schematron) accompanied with the Pseudo code, could really improve those 
Pseudo codes by making them less ambiguous, more accurate and precise. In 
fact, if both XSLT and XQuery and Schematron are provided, implementors 
and Web developers could choose any of these languages for testing Web 

So, my proposal is to combine some formalized rules (in 
XSLT,XQuery,Schematron,CLIX,...) with the current pseudo code in order to 
provide the test procedures available in several languages (pseudo code 

Don't you think it is a good idea to complete the current pseudo code with 
some implementable alternatives (some of them expressed in languages 
developed by W3C) from where people can choose (including pseudo code)?

Best regards.
Received on Wednesday, 6 December 2006 16:51:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:52:53 UTC