Re: About locating subject results and context

Hello Shadi,

Shadi Abou-Zahra wrote:
> Hi Chrisoula,
> 
> Good point! I think in this case, something more generic like "//a//p"
> would still catch such a change (I think that should work, no?).


Absolutely, it would work! My intention was point out that we have to be 
aware of context-sensitive errors, when trying to figure out how to 
locate errors. And by the way I am still wondering if we can claim that 
accessibility errors can always be defined free of context, alhough I 
could not find an appropriate example from the WCAG 2.0 test suite.

> In other words, we could rephrase this type of problem to "the sequence
> of <p> within <a> is invalid". If we define that all such
> "sequence"-type errors should be indexed with such an expression, we
> would cover a whole pile of errors. I argue that there are probably only
> a limited amount of "error types" or rather "indexing types". What do
> others think?

I agree. I think this is a pretty much generic way to capture such errors.

> However, one major issue is that we need to assume at least well-formed
> documents to use such pointers...

Unfortunately! I suppose however that if the HTML validator is able to 
report for non-well-formdness, then EARL should also be able to do that, 
no?

One thing to consider however is the following:

Do we care about persistency of errors, in the absence of well-formdness??

If not, we can just use line numbers for reporting these types of 
errors, like the HTML validator does..What do people think about this?

Regards,
Chrisoula


> 
> Regards,
>   Shadi
> 
> 
> 
> -----Original Message-----
> From: public-wai-ert-request@w3.org On Behalf Of Chrisoula Alexandraki
> Sent: Wednesday, March 23, 2005 18:27
> To: Gabriele Bartolini
> Cc: public-wai-ert@w3.org
> Subject: Re: About locating subject results and context
> 
> 
> 
> Hi Gabriele and all,
> 
> Let me clarify what I mean with an example:
> 
> Suppose we are reporting on tests against XHTML validation:
> 
> Sorry I couldn’t find a good accessibility example to explain this – but
> 
> according to the [scope for EARL] message thread, and specifically at:
> <http://lists.w3.org/Archives/Public/public-wai-ert/2005Mar/0056.html>
> EARL should be able to report also on validation errors.
> 
> If we have the following bit of invalid code:
> =============
> <a href="url.html">
>     <p>
>        Some silly text
>     </p>
> </a>
> =============
> 
> We have two options for locating this error:
> 
> a) By pointing to the parent element, e.g. //a[@href=’url.html’]
> b) By pointing to the structural info that is causing the error, e.g.
> //a/p
> 
> If we follow solution (a), then if we change the href attribute the 
> error will persist, but it can no longer be tracked. If we follow 
> solution (b), and we change the above code for example to the following:
> 
> =============
> <a href="url.html">
>     <b>
>        <p>
>           Some silly text
>        </p>
>     </b>
> </a>
> =============
> Again the error persists and also it cannot be tracked because the 
> expression //a/p  does not meet the specific paragraph element.
> 
> Does this make sense? Do you think it is something we have to take into 
> account?
> 
> Regards,
> Chrisoula
> 
> 
> 
> 
> Gabriele Bartolini wrote:
> 
>>Hi guys,
>>
>>   I want to show an example of locating subject results according to 
>>the techniques proposed by Chris and - partially - by me.
>>
>>   In particular, I refer to the issue raised by Chrisoula, regarding 
>>the context of an assertion. We did not have to time to clarify your 
>>issues during the conference, so I write now my thoughts in the
> 
> attempt 
> 
>>we can get to a productive result.
>>
>>   First, and please correct me if I am wrong, I believe that the 
>>context problem is overall an issue for the test itself, not the
> 
> report, 
> 
>>and therefore for the developer of automatic accessibility validators 
>>for example. Let me explain. If I have to discover an accessibility 
>>barrier based on an image inside an anchor, that should be the 
>>validator's responsibility to pry it out, not the report.
>>
>>   Second, even if that's not the case, as Wendy pointed out during
> 
> the 
> 
>>meeting, using "multi-level (intelligent) fuzzy pointers" would
> 
> provide 
> 
>>several ways and opportunities to locate the result in a persistent
> 
> way.
> 
>>    Let me explain with an example. I beg your pardon Chris if I
> 
> borrow 
> 
>>some of your code. With a fuzzy pointer we could use different 
>>strategies to match a location, based on:
>>
>>1) xpath-like expressions : /HTML/BODY/TABLE/TR/TD/TABLE/TR[1]/TH/IMG
>>2) ids: id('my-table')/TR[1]/TH/IMG
>>3) proper fuzzy pointers, which vary from case to case - as Chris 
>>suggested - based on element and attribute names
>>4) ranges? but, how to specify them? borrow some of the syntax from 
>>xpointers?
>>5) ... other strategies that have yet to come ...
>>
>>    As you can see, IMHO using the xpath-like expression we can have a
> 
> 
>>good understanding of the context of an element.
>>
>>    Waiting for your comments.
>>
>>Ciao,
>>-Gabriele
>>-- 
>>Gabriele Bartolini: Web Programmer, ht://Dig & IWA/HWG Member, 
>>ht://Check and ht://Miner maintainer
>>Current Location: Prato, Toscana, Italia
>>me@gabrielebartolini.it | www.gabrielebartolini.it | ICQ#129221447
>> > "Lasciate ogne speranza, voi ch'intrate", Dante Alighieri, Divina 
>>Commedia, Inferno
>>
>>
>>
> 
> 

-- 

___________________________________________
Chrisoula Alexandraki

Foundation for Research and Technology - Hellas (FORTH)
Institute of Computer Science (ICS)
Human-Computer Interaction Laboratory
Centre for Universal Access and Assistive Technologies
Science and Technology Park of Crete
Heraklion, Crete
GR - 71110 Greece

Tel: +30 - 2810 - 391754
Fax: +30 - 2810 - 391740
email: chrisoula@ics.forth.gr
URL: http://www.ics.forth.gr/hci/

Received on Tuesday, 29 March 2005 13:27:11 UTC