Re: ERT Action Item: Use Case Scenarios for EARL

Hi Giorgio,

    I apologise from now for this long email, but I could not reduce it 
size anyhow!

    Also, I have been extremely busy these days and I will bulk-reply from 
now to the next few hours before the meeting to a week of e-mails (if 
possible). :-)

At 16.36 30/03/2005, Giorgio Brajnik wrote:
>WAI should require that whoever posts the new logo, links it to a RSS-like 
>feeder that yields an EARL report that justifies the claimed level of 
>accessibility. [1]

I totally agree with you as far as the promotion of EARL is concerned. 
However, I am wondering how one can prove their tests truthfulnes, by 
providing concrete facts (EARL reports) that "clearly" state what they are 

I want to discuss this real case, by providing some examples and thinking 
loudly the steps I would follow. I have not also well understood the logic 
behind the RSS feeder and how you would integrate it in our case; so please 
bare with me if some of these concepts are a bit unfamiliar to me.

Let's assume I want to assess accessibility conformance of a website and 
provide technical reports produced in EARL by different evaluation tools.

First, when talking of a website I have several resources that are 
logically connected to each other that need to be assessed. I have a couple 
of options that come to my mind:

1) site-wide check (check all the pages - crawling can be performed 
"manually" or automatically, depending on the available tools - for 
instance a tool like ht://Check can automatically crawl a website for 
accessibility checks, Bobby can't)
2) perform a sampling operation and select a discrete number of pages (5 
for instance) and manually check them
3) evaluate the home page

Of course, most of the strategy to be taken, depends on the evaluation 
tools that are available and their features in terms of crawling resources 
(follow internal links).

In the specific case, given that ht://Check performs site-wide 
accessibility checks, I can check the whole website by using it and have, 
at the end, an exhaustive and accurate report based on the set of automatic 
checks that the application is able to do.

However, I want to use different tools as well so that I can compare the 
results and, at the same time, provide final users with a variety of 
technical reports of accessibility checks.

Assuming that these tools theoretically provide EARL support, I could use 
Bobby or Torquemada or another one. If they give me the chance to perform a 
site-wide check like ht://Check I can go on with it. If they can't, I have 
to choose between option 2 or 3, or a mix of the 2.

For instance, I decide to get 5 pages plus the homepage and evaluate them.

Also, as I have to manually perform an evaluation in order to claim WCAG 
1.0 level 2, I could use a tool like Wuhkag in order to produce an 
accessibility policy and an EARL report (which is not yet done - but again 
let's think in a theoretical way).

At the end I have:

1) ht://Check's report
2) Bobby's report for 6 pages
3) Torquemada's report for 6 pages
4) other evaluation tools EARL reports for the 6 pages
5) a Wuhkag EARL report which clearly states all the checkpoint that have 
been passed based on a human assertion

My first question is. Can I easily link all these reports to the WAI button 
I have displayed in the home page or in the accessibility policy page? I 
understand that you too, Giorgio, had some concerns about this point, 
hadn't you?

I guess we should think of a sort of aggregator of EARL reports to be 
"required" in conjuction with the use of compliancy images like the ones we 
were talking about. Could this be obtained by a main EARL report which 
links the other and more specific ones?

Thank you for your comments.

Gabriele Bartolini: Web Programmer, ht://Dig & IWA/HWG Member, ht://Check 
and ht://Miner maintainer
Current Location: Prato, Toscana, Italia | | ICQ#129221447
 > "Lasciate ogne speranza, voi ch'intrate", Dante Alighieri, Divina 
Commedia, Inferno

Received on Tuesday, 5 April 2005 15:00:18 UTC