Re: [Fwd: Re: Location Property]

Hi Chris,

Great summary of the situation and thanks for the proposal, it's something to start working with. I'll put it on the agenda for this Tuesday's call. Please find a couple of comments below:


Al Gilman wrote:
> 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.

Agreed. Here is a previous attempt to list generic patterns for locating errors according to the type of test/error (i'd be happy to help work more on that if you think it is usefull):
  <http://lists.w3.org/Archives/Public/public-wai-ert/2005Mar/att-0062/errors>


>> 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.
> 
> I don't see how we can do diagnostic assist without cacheing an image
> of the exact message that came over the wire.

There are several issues here: 1. different document types, and 2. content changing over time. I think we agreed not to make issue 2 a top priority right now because it makes the whole idea way too complex. We *are* addressing the content in a more robust way in EARL right now (storing HTTP request/response pairs). We can also built in caching specific content types (such as images) or using signatures later on.


>> 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.

Maybe not a required standard but why not propose a method to approach basic Web pages? We will not be able to address all content types but I think we can make a pretty good attempt at some of the basic (and common) ones like HTML, XHTML, CSS, etc. As EARL is then taken up by developers and technologies evolve (eg. PDF does use more XForms etc), we may be able to narrow down the constraints.


>> 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.

Both? ID for machines, title & description (of the location, not of the actual result/error) for humans. This is especially useful for tests or content that is difficult to address programatically and needs to be described.


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

Yes. Though we should heavily promote XPath and provide guidance on how to do expressions. How about earl:offset for byte values as well?


>> 6) The location properties apply to the content evaluated and do not 
>> necessarily locate the error when the document has been modified.

Agreed, this is another beast. I think with the current catching of the HTTP request/response we can at least nail down that the content is different. How it changed may be something for later (even though it is good to always keep it in the back of our heads).


>> 7) Other location 'hint' properties may be included for finding the 
>> error if the document is modified.

Do you mean something like earl:checksum or similar?


>> <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>

I suggest something like this (not tested):

<earl:Locations rdf:parseType="Container">
  <earl:Location rdf:id="...">
    <rdf:Bag>
    ...
    </rdf:Bag>
  </earl:Location>
  <earl:Location rdf:id="...">
    <rdf:Bag>
    ...
    </rdf:Bag>
  </earl:Location>
  ...
</earl:Locations>

This would allow multiple occurences of a result within a single resource (i think something like this had been posted to the list earlier already).


Regards,
  Shadi


-- 
Shadi Abou-Zahra,     Web Accessibility Specialist for Europe 
Chair and Team Contact for the Evaluation and Repair Tools WG 
World Wide Web Consortium (W3C),           http://www.w3.org/ 
Web Accessibility Initiative (WAI),    http://www.w3.org/WAI/ 
WAI-TIES Project,                 http://www.w3.org/WAI/TIES/ 
Evaluation and Repair Tools WG,     http://www.w3.org/WAI/ER/ 
2004, Route des Lucioles -- 06560, Sophia-Antipolis -- France 
Voice: +33(0)4 92 38 50 64           Fax: +33(0)4 92 38 78 22

Received on Thursday, 11 August 2005 15:14:31 UTC