RE: Mini Market Survey for Evaluation Description Language

<LenSaid>
1. If you evaluate web sites  how useful would it be to
- combine results from two or more tools?
</LenSaid>
Mucho Mambo Useful.

This allows a myraid of different tools, people, experts, whomever to
evaluate one document and each record assertions about it.  In this way I
can combine the output of my automatic tool and an experts manual checks
into one seamless data source.  This is the only structure I see for
creating complete accessibility evaluations that are interpretable (is this
a word?) at the machine level.  Without a structure for combining a group of
assertions about a document's evaluation creating a workflow that ensures
compliancy is impossible.

<LenSaid>
- have results in an XML/RDF format that would enable you to create custom
reports (assuming tools to help write the transforms were available)
</LenSaid>
From what limited knowledge I have of RDF my understanding is that it is the
better language [the language?] for making assertions about documents.  My
concern is that the mechanism for pointing into the document needs to be
flexible enough to handle pointing into all manner of code.

The custom reports will be a cinch once a standard schema is in place.  The
ability to create such reports is a key factor in making accessibility a
possibility.

<LenSaid>
2. If you develop web sites: how useful would it be to
- input the results into a web site authoring tool, so the authoring tool
could
     . flag accessibility issues specified by EARL in the tools display of
the site and code
     . allow you to accept or reject any suggested changes in the page
(assuming such changes were included in the
        EARL output)?
</LenSaid>
Correct me if I am wrong but is this basically a wizard that reads in EARL
and spits out a "fixed" page?  I have some pretty specific opinions about
fixing but I will voice them in reponse to question 4.

<LenSaid>
4. If  you (or your organization) develop web site authoring tools, how
much interest would there be adding features to input EARL  so that users
would have the capabilities described in (2)?
</LenSaid>
The big issue here is that large websites are:
	a. Dynamically generated
	b. Hand tweaked

When I am evaluating a webpage I basically evaluate a URI that resolves to a
single page.  www.cnn.com for example.   When I go through and evaluate this
page I come up with some set of violations which I promptly write out to
EDL.  Then I read in the EDL and page into InFocus (A-Prompt, whatever...)
and proceed to retrofit the page with no diagnostic prompting.  I now have
an accessible HTML page, AAA compliant and so on.

Trying to put this retrofitted HTML back into CNN's system, however, proves
fruitless.  The one logical HTML document is comprised of the output from a
massive set of server-side code.  So while I have created an accessible
document, there is no easy way to get the retrofitted HTML back into the
system.

What I have seen work at large websites, though, is to give the developers
the entire set of violations, or a report generated from them.  The
developers then take the violation set back and figure out a way to make the
"page" compliant.

Thus to make a bold statement: There is no set road to an accessible page
but the first step is always a thorough evaluation.  While I believe that
repair tools could, at some point, act based on EARL (EDL, whatever) I see
very little near term economic sense in building a repair tool that operates
on it.  I do, however, see a great deal of economic benefit in developing a
standard evaluation language for evaluation and reporting tools to operate
on.

<LenSaid>
5. If you (or your organization) develops web site evaluation tools, how
much interest would there be in
      a. outputting an EARL file
</LenSaid>
Since we are already outputting to XML and familiar with it is my assumption
that switching to EARL should be pretty easy.  As such I would say there is
a great deal of interest.

My only note would be that whatever language we choose has to work with Xerc
es, Xalan and JDOM ;-)

<LenSaid>
      b. inputting an EARL file from another tool to integrate with the
info your tool picks up?
</LenSaid>
*Integrate*?  Does that mean somebody needs to build the RDF accessibilty
resolution engine?  or can we simply let the RDF assertions overlap one
another.

TimS

<DISCLAIMER>
I HAVE BEEN WRITING CODE FOR THE LAST 72 HOURS AND MUST SHIP A PRODUCT 12
HOURS FROM NOW.  I MAY CURRENTLY NOT BE MAKING ANY SENSE.  I AM UNAWARE OF
THIS.  AT SOME POINT I WILL RETURN TO MY NORMAL, CHARMING SELF, HOWEVER FOR
NOW I RESERVE THE RIGHT TO BE A LITTLE *OFF*.
</DISCLAIMER>

Received on Thursday, 14 December 2000 23:36:01 UTC