Re: Location Property

At 9:58 AM -0400 7/18/05, Chris Ridpath wrote:
>The current draft EARL schema does not seem to have any properties 
>to describe the location of the error. We've discussed these issues 
>earlier on the list [1] and I believe we need these properties and 
>that they should be part of the assertion. Here's my formal proposal:
>
>1) Each assertion that describes an error needs to describe where 
>the error occurs. For example, if an HTML page contained the error 
>"image is missing an alt attribute" we need to state which image. 
>It's not enough to simply state that the content contains an error, 
>you've got to state where it is.

There are two choices here:

- assume a perfect [parse or schema validation] of the page you are
critiquing and use logical addressing as with XPath, or

- use the concrete values that miscompare and assert how you are
interpreting them, in the context of the as-received document, as
matching the generic pattern in the testable assertion.

Pseudocode:

Taking
  testAlt =
  {text fragment} found as
   {syntax path to ALT attribute} at
     {physical location} -- using the DAISY 'bookmark' start/end 
methods of location
  to match role
   "the ALT text" in rule
   {reference to rule stating "in an image link, the ALT text for the 
image should describe the link href target"}
and
  testTargetDoc =
  {web document} found as
    {timestamped URI} to match the role
  "the link href target" in
   { the same instance-pattern matching the rule-selector-pattern, implied }
Then rule.assertion(instance.data) = False.

The point is that you need to spell out the selector-pattern that
matches instances where an accessibility requirement predicate is to
be tested, and the specific matching instance-data pattern that you
are referencing in any statements as to whether the requirement
predicate applied to the instance data succeeds or fails.

This is like an actual parameter list as opposed to a formal parameter list.

The master statement of a procedure contains the formal parameter
list. The statement of the testable assertion creates a formal set o
roles for instance data to play in the application of the rule.

A procedure invocation contains an actual-parameter list. For
simplicity assume named association between formal and actual
parameters, not positional association.

In any case, what we need here is an association between formal
(generic to the rule-pattern) items in the testable assertion and
actual, specifically identified instances of the relevant roles in the
generic rule.

>2) The location properties that we use to describe the error is 
>dependant on the accessibility test that is performed. For example, 
>the properties used to describe HTML errors will be different from 
>the properties used to describe errors in Flash or PDF.

Yes, the form of physical addressing will be dependent on the format
of the document instance. Maybe the logical addressing, too. I hear
that Adobe is working on a binding of XForms in PDF. Do they have any
plans to support XPath over their structure model? Now that Flash
comes from the same company, we are close to converging on a
convergence strategy. The problems with "no heredity model for
objects" in Flash doesn't affect the structure of an assembled
document.

I would actually suggest that you adopt some low-level method owing
to the prevalence of invalid code on the actual Web.

If everything on the Web were at least well-formed XML, we could use
XPath and be fat and happy.

But you also have to allow for browser-sniffing and all the other
reasons why the "entity body" in the HTTP message is not reproduced
from hit to hit on a given URI.

I don't see how we can do diagnostic assist without cacheing an image
of the exact message that came over the wire.

The low-tech way to exploit this is

a) IF you get a clean parse, give a logical location in the parse
tree b) in all cases back this up with a hard pointer into the source
you saved, as encoded on your system. Be prepared to forward that as
an octet-stream with octet indices.


>3) The location properties should be precise and interoperable. We 
>need to describe as clearly as possible where the error occurred and 
>this should be done in a standard manner so the results may be 
>exchanged with other programs. I suggest that for HTML errors we 
>require that at least one xpath expression be used to describe the 
>accessibility error.

Interoperable, yes.  Standard, no.  Writers of this stuff only have 
to express locations in ways that
the receiver can interpret succfully.  We don't need [or want] to try 
to impose a canonical representation for
locations.

>4) More than one location property may be required. For example, to 
>describe a series of links that should be grouped with a list 
>element, properties to identify all the links in the group would be 
>required. The number of location properties is dependant on the 
>accessibility test. If more than one location property is used then 
>each property must have a title to describe itself.

ID, not title.

Consider UL members.  A bag.  you want to keep them straight, but 
their relationship to the discrepancy report does not imply a title. 
Only an opaque ID.  The roles that matter in the test objective are 
not necessarily distinct.  If you want to say that the UL failed to 
articulate the common characteristics of the items in the list, then 
the only significant thing about each item is that it is in the list, 
not what it is  in any global sense.  You just need a basis for 
iterating over the items to account the common characteristics that 
are shared across all of them.

>
>5) Other optional location properties may be included. For example 
>line and column numbers could be included as well as xpath 
>expressions.

See above for suggestions that are more robust.

>6) The location properties apply to the content evaluated and do not 
>necessarily locate the error when the document has been modified.
>
>7) Other location 'hint' properties may be included for finding the 
>error if the document is modified.
>
>Example EARL code for discussion:
>
>This example locates an image within the document that has failed 
>the test "all images must have an alt attribute".
>
><earl:Location>
><rdf:Bag>
><rdf:li rdf:parseType="Resource">
><dc:title>key-element</dc:title>
><earl:xpath>/html/body/p/img[@src="rex.jpg"]</earl:xpath>
><earl:column>24</earl:column>
><earl:line>9</earl:line>
></rdf:li>
></rdf:Bag>
></earl:Location>
>
>This example locates the anchor that has failed the test "all source 
>anchors contain text that describes the link destination". Here is 
>the problem HTML code:
><a href="spending.html"><img src="more.gif" width="30" height="10" 
>alt="image"/></a>
>
>The problem is that the alt text for the image does not describe the 
>link destination.
>
><earl:Location>
><rdf:Bag>
>
><!-- the anchor element -->
><rdf:li rdf:parseType="Resource">
><dc:title>key-element</dc:title>
><earl:xpath>/html/body/p/a[@href="spending.html"]</earl:xpath>
><earl:column>109</earl:column>
><earl:line>9</earl:line>
></rdf:li>
>
><!-- the image within the anchor -->
><rdf:li rdf:parseType="Resource">
><dc:title>link-text-image</dc:title>
><earl:column>165</earl:column>
><earl:xpath>/html/body/p/a/img[@src="more.gif" and @alt="image"]</earl:xpath>

Is it legal XPath to do this in one fell swoop with a path something like

/html/body/p[13]/a[@href="spending.html"]/img[@src="more.gif" and @alt="image"]

.. I assume that in this image link there is only one image so that 
we don't really
need the @src value in the path.  [even 'though all <img> elements on this page
have "image" as their @alt value...]

Al

><earl:line>9</earl:line>
></rdf:li>
>
></rdf:Bag>
></earl:Location>
>
>Comments appreciated.
>
>Cheers,
>Chris
>
>[1] http://lists.w3.org/Archives/Public/public-wai-ert/2005Mar/0092.html

Received on Tuesday, 19 July 2005 14:09:53 UTC