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/