- From: Shadi Abou-Zahra <shadi@w3.org>
- Date: Fri, 8 Apr 2005 13:17:40 +0200
- To: "'Chris Ridpath'" <chris.ridpath@utoronto.ca>, "'Charles McCathieNevile'" <charles@sidar.org>, <public-wai-ert@w3.org>
Hi, Chris Ridpath wrote: > http://checker.atrc.utoronto.ca/test1-earl2.html Looking really good! Except that we still need to finalize what exactly we put into the <rdf:li>... > <!-- this describes the anchor --> > <rdf:li rdf:parseType="Resource"> > <earl:line>9</earl:line> > <earl:href>spending.html</earl:href> > <earl:xpath>/html/body/p/a</earl:xpath> > <earl:name>anchor</earl:name> > </rdf:li> First of all, I think earl:name would only repeat what is already written in the HTML spec. What is it actually used for? Secondly, I think that *if* we can use XPath to reference the error, then we can just use something like this to describe all of the above in one go: "//a[@href='dogs.html' and value()='click here']" IMO, this is more robust and persistent. But again, this only works on markup or in best case on (semi-)structured documents. What do we do with other types of documents? > I think we can use this strategy for describing most all > accessibility errors. > Comments? It seems such strategies may work well for documents that have some sort of structure like HTML, or the XML family. For less structred documents such as CSS-, script-, or text files, we may only be able to provide line numbers but that strikes me as too little. For binary file types such as PDF, Flash, or DOC, it looks even worse... Regards, Shadi
Received on Friday, 8 April 2005 11:17:30 UTC