Re: TAW Checker approach

Dear all,

I've been following discussion and would like to attend the upcoming 
call on behalf of the W3C Evaluation and Repair Tools Working Group:
  - <http://www.w3.org/WAI/ER/>

Currently there are many evaluation tools for Web accessibility and we 
are maintaining a list of many of them in a sortable database:
  - <http://www.w3.org/WAI/ER/tools/>

However, currently we are focusing on finalizing the Evaluation and 
Report Language (EARL) which is an RDF vocabulary to record test 
results. It's primary use is for evaluation tools to be able to export 
their testing results in platform-independent and machine-readable 
format. These results could be used by authoring tools (to integrate 
different evaluation tools) or to compare the output by different 
evaluation tools. Please find some references on EARL below:
  - <http://www.w3.org/WAI/intro/earl.php>
  - <http://www.w3.org/TR/EARL10-Schema/>
  - <http://www.w3.org/TR/HTTP-in-RDF/>

There are several tools that output EARL results including the W3C 
Validator, Hera, HiSoftware, and TAW. We expect many more evaluation 
tools may support EARL once it reaches Recommendation stage (we are 
aiming for Last Call in the very near future).

Anyway, there seems to be a strong relationship and synergy between Web 
accessibility evaluation tools and mobileOK checkers. Personally I think 
that several evaluation tool developers may be interested in supporting 
mobileOK beside WCAG or other standards. Maybe we should think about 
supporting these developers by defining a common testing framework?

Most Web accessibility evaluation tool developers have already started 
to define some kind of languages to describe tests. The aim is to have 
the tool itself be an engine for pluggable tests, for example to test 
compliance to different standards (WCAG 1.0, WCAG 2.0, Section 508, 
etc). Here are links to some of these languages, I am sure there are 
many more I am not unaware of or that are not been put in public space:
  - <http://eval.webaim.org/> (LRAE is a well documented language)
  - <http://checker.atrc.utoronto.ca/index.html>
  - <http://www.it.uc3m.es/vlc/waex.html>

I hope this is sufficient information and background for a starter 
*grin*, please let me know if you have questions or comments.


Regards,
   Shadi


Sean Owen wrote:
> Thanks Miguel. Sorry everyone I have not been helping drive progress
> here lately.
> 
> So, we have some medium-sized differences of opinion about how to
> structure the reference implementation but nothing that can't be
> resolved. As I see it, here are the key "proposed resolutions" from
> the previous thread on this topic:
> 
> 1. Implementation should produce an intermediary DOM / XML document
> 2. Some tests should be implemented as XSLT transformations
> 3. The test output should be made available as a detailed DOM / XML 
> document
> 
> I share Miguel's concern about the cost versus benefit of 1 and 2, but
> support 3. I hear at least two voices in support of 1 and 2 though.
> 
> Miguel, can you share any of your TAW code? the design of a working
> implementation may be useful for everyone to see.
> 
> How to proceed? First, let's have that call we were talking about. How
> about 10am EST / 4pm CET, Monday, February 26? If anyone has an easy
> way to set up a conference bridge, go ahead. If I hear nothing I'll
> figure out how to set one up tomorrow.
> 
> The key questions, in my view, are:
> 
> A. We have three relevant implementations (Dom's, .mobi, TAW). I've
> gone off and started defining a fourth. Are we comfortable with that?
> The fourth implementation's goal is to be independent of anyone's
> particular usage or deployment, but, also conceivable usable by the
> W3C and .mobi and TAW.
> 
> B. Ownership. Things get done when they have owners, and in software,
> one architect is good. I have the time and willingness to drive this,
> but, am concerned I won't fairly represent the design goals of
> everyone (in particular regarding points 1 and 2 above.) So... who
> else wants to work a lot on this and can start writing code?
> 
> C. Find a resolution to items 1, 2 and 3 above.
> 
> D. Next milestone -- what can we do before the final release of
> mobileOK Basic Tests 1.0
> 
> 
> Sean
> 
> 
> On 2/16/07, Miguel Garcia <miguel.garcia@fundacionctic.org> wrote:
>>
>> Hello everybody and sorry about the delay.
>>
>> We have had a lot of work in other issues so we haven't answered 
>> before. We'll explaining the approach of TAW checker in relation with 
>> the ideas discussed in the list and share some thoughts.
>>
>> We think the declarative approach could give more extensibility and 
>> portability than a language specific library. But like Sean said 
>> before, the generation of the meta document can't be made in language 
>> agnostic way so the portability is not 100% possible. Also we think 
>> that this developing (defining metadoc, share the work, put all 
>> together) would be much more expensive that the Sean Java library. 
>> Which would be the desirable date to get the reference checker?
>>
>> In TAW checker we opted for a Java library (similar to the prototype 
>> offered by Sean), we'll explain in more depth in another mail.
>>
>> In addition we want to add some commentaries based in CTIC's 
>> experience developing TAW. Just note TAW was originally conceived as 
>> an a web accesibility (WCAG 1.0) checker tool and the solutions were 
>> taken with that aim in mind.
>>
>> Our first problem was the majority of web pages are not well formed so 
>> we first thought about using a source repairer tool. But we discarded 
>> source repairer based solutions because of the traceability of the 
>> errors or warnings. If you are a user you want to know where is the 
>> problem that is which element caused it and where is inside the source 
>> code. An option is maintain a map between original source code and 
>> repaired code. We opted for instead of using DOM parsers use another 
>> parser, specifically HTML Parser library. A LGPL library for parsing 
>> (x)HTML documents that doesn't require a well formed document.
>>
>> Perhaps it would be better to combine both solutions, if the document 
>> is well formed create a DOM tree otherwise enter in a 'quirks mode' 
>> and use a HTML parser.
>>
>> If a repair tool is used, ¿all the checkers should use the same tool 
>> in order to generate the same results?.
>>
>> Next we have some dificulties with encodings. Sometimes documents are 
>> not encoded as declared and these could lead in fatal errors during 
>> parsing. So we do a preprocessing to detect the real encoding of the 
>> document before parsing it.
>>
>> Regards
>>
>> ******************************************
>> Miguel García
>> Fundación CTIC
>> -Centro Tecnológico de la Información y la Comunicación-
>> E-mail: miguel.garcia@fundacionctic.org
>> Tfno: +34 984 29 12 12
>> Fax: +34 984 39 06 12
>>
>> Parque Científico Tecnológico Gijón-Asturias-Spain www.fundacionctic.org
>> ******************************************
>>
>>
>>
>>
>>

-- 
Shadi Abou-Zahra     Web Accessibility Specialist for Europe |
Chair & Staff 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, 22 February 2007 18:09:29 UTC