Re: Official WAI Report Form

to follow up on what Daniel Dardailler said:

> I have what I think is a good work item for the ER IG.
> 
> A summer student (Eric Cabrit) and I have been playing with the idea
> of a W3C/WAI "endorsed" report and tracking facility.
> 
> http://www.w3.org/WAI/ER/report
> 
> It's not operational yet, no active CGI behind the scene, and the
> message preview is just a template, but we're not far from having it
> working and most of the issues we have right now are I think issues
> for the IG to deal with, the WG just acting as an implementation
> pool.
> 
> Feedback is needed on several things, like:

>  - general idea of W3C/WAI providing such a report, good or bad,
>    useful or useless ?

The usefulness will be limited unless we can make it a verb in the
browser.  That is to say, the user does not have to handle the URL
of the offending page.  The browser should capture the URL of the
current page when the user invokes the "write a message" function and
provide it automatically to whatever else happens.

The usefulness will be greater if the tool applies analysis to
the site the user complains about, and does not just pass through
what the user can say.

There is already a "write a comment to the author" function in
Lynx.  Lynx users tend to be activist, so this is a potentially
effective linkage if we can make the connection there.

Chuck Opperman in the Boston meeting said that if someone would
implement the "write a letter of complaint" function in Visual
Basic that he would ensure it shipped with every copy of IE.

>  - what to do with the data: public or not, at what stage ? (current
>    model suggest that the data is not public right away but can if
>    nothing is done - with no definition of "nothing")

Nothing should go public unless manually reviewed by a trained
team member.  [That's little-t team, not W3C Team.]  I would like
to see W3C/WAI positioned as something of a fact-finder and
mediator.  In other words, perform a service which we can offer
to webmasters as "We can help you understand and respond to
complaints" as much as we offer to people with disabilities that
"We can help you get corrective action from webmasters."

By the way, the best solution would be if the W3C can decide to
offer this kind of service as regards usage of Web standards in
general, not just use of accessible web design practices.

>  - how to manage the liability risk for W3C (spammer, angry/insulting
>    reporters, few mistakes, plain wrong report, etc) 

Sometimes I think that reports should be eyeballed before they go
out on W3C letterhead, as it were.  Another tack is not to put
the W3C name on the first mail to the alleged offender but rather
to cc: complaintsW3.ORG .  Make it clear that the W3C knows about
the complaint and implicitly should be copied on responses.

>  - maintenance of data: when to delete entries, forecast of usage (is
>    human tracking of reports possible?)

Usage should be managed.  Use controlled populations of alpha and
beta testers.  If the process is working, figure out how to staff
the necessary manual review tasks.  We can tap advocacy organizations
for the latter; they can be trained on the tools and guidelines and
check for off-the-wall complaints.

>  - how to subset the Page Author guidelines for reference from this form?

Link key points to the web-present guidelines.  Don't subset.

One possibility is that only an executive summary message goes by
email, and that a detailed report with hotlinks to the reference
documents goes on the Web.  This means sending the offendor a
password through the email but that is still pretty private.  The
content MD5 of the complaint message could serve as a hash value
granting access to the page.

*** This does mean we need to freeze some anchor names for section
references.  These must be mnemonic and not counting values (no 
section 2_3, for example).  W3C docs have some pretty good anchor
name generation practices.  We can copy.  This involves a request
for action from WAI-GL for anchor names.  ***

>  - need to refine the outgoing message wording and identify how many
>    translation to provide ? 

It's pretty good.

Where it says "this database is not presently public" it should
rather say "the record of this complaint is not presently public."

Visibility should be controlled on a case-by-case basis, not the
whole database as a unit.

Other design details:

The individual checkoffs are a bit too technical.  I would
suggest that we put the free text summary of the problem first
and the "check all that apply" boxes below.  Or don't ask the
complainant for any discrete checkoffs and us a Bobby or
WebMetrics report to enumerate the technical description of the
problem.

There could be a two-step report development process:

User hits function key, writes prose summary.

Tool runs page through checker, puts together draft message.

User reviews message.  User is encouraged to delete items
that were not significant for their use.

User commits/sends message.  Tool posts it to database.
(this could be by cc: on email).

Oh, by the way: having the tool help in determining who the
complaint email goes to should be always on or at least default
to on.  Sniffing out the place to send complaints is one of the
areas where people could use help and a tool could do useful
stuff.  Subscribe to Thomas's Register.  Know who to escalate to
in the business sponsoring the website.  This is a key piece of
the program.

Al

Received on Tuesday, 11 August 1998 15:02:30 UTC