W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2003

RE: [techs] proposal to replace use of "rules"

From: Jason White <jasonw@ariel.ucs.unimelb.edu.au>
Date: Wed, 29 Jan 2003 18:42:44 +1100
Message-ID: <15927.34292.152516.22172@jdc.local>
To: gv@trace.wisc.edu
Cc: "'Wendy A Chisholm'" <wendy@w3.org>, w3c-wai-gl@w3.org

Gregg Vanderheiden writes:
 > 
 > That works ok for the techniques doc,  but for the checklists we need
 > checklist items.
 > 
 > There may be 3 or 5 techniques for a success criteria.   To meet the
 > criteria you would not need to do all 5.  but you may have to do one of
 > them.  Or two of them. Or some combination or another.

I suppose it depends on how you encode them and whether you are
referring to the source file (the XML document from which the
techniques are generated) or the output documents - techniques
documents and checklists. For example:

<and successcriterion="id"><technique><statement>[statement of first technique]</statement>
[other required/optional elements]</technique>
<technique><statement> [statement of second
technique]</statement> [other required/optional elements] </technique></and>

which means that in order to meet the success criterion you have to
implement both of the techniques; the checklist item would be
generated by extracting the contents of the two STATEMENT elements,
inserting "and" between them and supplying appropriate styling to make
the layout clear in the final presentation. As a result, there are
checklist items in the generated checklists but no checklist items in
the XML source. That is, the checklist items are generated from the
techniques during the output processing.

A disjunction might be written:

<or successcriterion="id"><exception>there are no <code>IMG</code> elements in the document</exception>
<technique><statement>every <code>IMG</code> element in the document
has a non-null <code>ALT</code> attribute that provides a text
equivalent for the image.</statement> [other details and examples of
ALT attributes] </technique></or>

The above element names are meant to be self-explanatory and easy to
understand for purposes of this e-mail message; I am not proposing
them for inclusion in a schema. That is, if you don't like my choice
of element names, please don't interpret them as a serious, well
considered proposal.

I think it is an open question whether we want to mark up the
techniques in this or a similar manner. There may be advantages for
purposes of testing tools, test suites and so forth, and it wouldn't
mean much extra work for the technique author.

Returning to Gregg's point, in the generated checklists there will be
checklist items composed of one or more techniques; in the source XML
there may not be checklist items depending on how we decide to mark up
the techniques. I close with the observation that it is usually better
to capture more semantics in the XML vocabulary in that it increases
the flexibility with which the data can be transformed and used. On
the other hand it does create somewhat more work in developing the
output transformations. Extending the above ideas one can envisage:

<or successcriterion="id"><and> [technique 1] [technique 2]</and> [technique 3] </or>

Trnaslation: to meet this success criterion you have to implement
either technique 1 and technique 2, or technique 3.
Received on Wednesday, 29 January 2003 03:02:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:21 GMT