Re: proposal for accessibility report tool

> Step 1
> Welcome to the Web Accessibility Reporting Tool.  This is a five step 
> process.  You may cancel at any time.  A report will not be sent until the 
> final step after you have pressed the submit button.
> 
> Please enter the URL of the page you are reviewing (or use Copy&Paste from 
> your browser). [yourURL]  [submit]

My original starting page was about that long but then various people
insisted that more introductional text gets added, so now we have
/WAI/report, which is a little longer than that.

So we need to revisit this shortness vs. informational issue.
 
> Step 2: Review existing reports for [yourURL]  [submit]

I think we can get rid of step 2 (review) for now, and see later if we 
need to handle duplicate more seriously.

> Step 3: Identify Problems With [yourURL]
>    1. I want to let the site's maintainer know that I can't use the site 
> [radiobutton1]
>    2. I want to provide a technical review of the site by using the WCAG 
> checklist [radiobutton2]
> [submit]

I'd favor a Step 3 (2 if we get rid of dup analysis) that asks for
simple feedback already, with a fork at the bottom to either submit
the simple stuff or go thru the advance WCAG form before submitting.
 
> Step 4:  Providing feedback
> [author e-mail]
> [your e-mail]
> [your name]
> 
> if radiobutton 1
> I find this site difficult to use (select all that apply):
>    [checkbox] with a screen reader.
>    [checkbox] with a screen magnifier.
>    [checkbox] with a dynamic braille display.
>    [checkbox] without a mouse.
>    [checkbox] without a standard QWERTY keyboard.
>    [checkbox] without sound.
>    [checkbox] without sight.

I wonder how useful this information is going to be when it reaches
the webmaster/author. I assume that the message sent will have pointer
to various documents detailing the kind of problems that have been
encountered but the more generic we are in the form at that point, the
harder it's going to be able to pinpoint issue/solution for the
webmaster.

I object to the term "standard QUERTY" :-)
(in France we use AZERTY, and other country use other layout)
I suggest standard keyboard, simply.

BTW, this section is similar to the current "Subjective rating" that's
currently being proposed in the WAI Report; it's both simpler (no
level of accessibility asked, just boolean), and more complex
(introduced concept such as screen reader, magnifier, dynamic
braille).

I would tend to keep only the simple stuff:

    [checkbox] without visual.
    [checkbox] without a mouse.
    [checkbox] without a regular keyboard.
    [checkbox] without sound.

> I also find that I
>    [checkbox] can not use the controls because they change too quickly.
>    [checkbox] can not access all of the links available on the page.
>    [checkbox] can not access all of the information available on the page.
>    [checkbox] can not comprehend the information on the page.
>    [checkbox] can not use the page because of too much movement.
>    [checkbox] can not read the page because of poor color contrast.
>    [checkbox] can not make sense of information in tables when the table is 
> linearized.
>    [checkbox] can not get to information in frames.
>    [checkbox] do not know what is presented in a script, applet, or plug-in 
because I do not have the right software.

This might prove useful but would have to be reworked based on real
user experience.
 
Do we want a free text field as well ?

> Browser [picklist]
> Assistive Technology [picklist]
> other [editbox]

Or is this "other editdox" supposed to cover unexpected issues, not
just unexpected tools ?


> WCAG Priority 1 checkpoints:

I'm in favor of making a selection, rather that including all of the
60 or so checkpoints.

Received on Tuesday, 30 November 1999 07:51:05 UTC