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:
<blockquote
cite="http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#H39">
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.
</blockquote>
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
developers.
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
pages.
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
included).
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.