W3C home > Mailing lists > Public > public-wai-ert@w3.org > March 2005

RE: About locating subject results and context

From: Shadi Abou-Zahra <shadi@w3.org>
Date: Fri, 25 Mar 2005 10:47:16 +0100
To: "'Chrisoula Alexandraki'" <chrisoula@ics.forth.gr>, "'Gabriele Bartolini'" <me@gabrielebartolini.it>
Cc: <public-wai-ert@w3.org>
Message-ID: <002f01c5311f$a1af61e0$b9c80b50@K2>

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

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?

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

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 Friday, 25 March 2005 09:47:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:25 GMT