Hello,

Thanks for this feedback. As you can imagine, testing accessibility is difficult. We're hoping that we can get it right once, and then provide an accessible CAPTCHA for everybody. I really appreciate you sharing your technical expertise in this matter.

On 5/25/07, Gregory J. Rosmaita <oedipus@hicom.net> wrote: 
the image that enables one to play the audio alternative
lacks alt text, which is a REQUIRED attribute for an image
declaration in HTML4x/XHTML1;

[ http://www.w3.org/TR/html401/struct/objects.html#h-13.2]
[http://www.w3.org/TR/html401/struct/objects.html#alternate-text]
[ http://www.w3.org/TR/html401/appendix/notes.html#accessibility]
[http://www.w3.org/WAI/References/HTML4-access]

the list of graphical elements reveals that there are actually
3 button-type objects that are part of the form, and essential
to anyone who actually needs the audio alternative:

red/reset
red/audio
red/help

MUST be ALT-texted as follows:

<img src="red/reset" alt="Reset"
<img src="red/audio" alt="Audio Alternative"
<img src="red/help" alt="Help

It turns out that the <a> elements around these have a title attribute. But it looks like that is not sufficient for audio browsers. I'm going to fix this over the weekend.
 

the image that serves as the hyperlink to the audio alternative is
not a form control; it should be a BUTTON, so it is in the form's
TABINDEX order, not outside of the form as a javascripted link;

My understanding is that the <a> element is normally in the tab index. However I actually took it out for the ease of visual browsers. Imagine you have a form with the following elements:

  1. Name
  2. Blog Comment
  3. reCAPTCHA
  4. Submit (a button)
Visual users should be able to interact with the form via the keyboard only.

I think that those using technology such as screen readers would benefit from a different layout & tabindex from visual users, so we may need a dual path.


[http://www.w3.org/TR/html401/interact/forms.html#edef-BUTTON ]

using the type="button" push-button mechanism to which to attach
the script that calls the audio alternative.

<button type="button" name="audio-alt" accesskey="r"
title="Alternative Audio CAPTCHA Key"></button>

i would STRONGLY suggest that an ACCESSKEY be associated with
the audio alternative - perhaps 'r' for read (it won't steal most
browsers' menu hotkeys)

[http://www.w3.org/TR/html401/interact/forms.html#h-17.11.2]
[ http://www.w3.org/TR/WCAG10-HTML-TECHS/#link-accesskey]
[http://www.w3.org/TR/WCAG10-HTML-TECHS/#forms-keyboard-access]

I think for audio users it may make sense to provide a different set of buttons that are highlighted (in an auditory sense). I'd like the experience to be something like this:

This is a security mechanism in which you will hear eight numbers. To hear the numbers click here. If you weren't able to hear the numbers click here to get a new challenge. Now enter the numbers here.

What is the best way to achieve this experience for screen readers?
 

=======
ISSUE 3
=======

the audio alternative doesn't play if you don't have QuickTime
installed, and most people who will benefit from an audio alternative
will NOT have QuickTime installed, as it is infamous for not playing
well with assisstive technologies;

We had trouble making the audio work for people (which is why we have the can't hear this sound link). What's the best way to embed sound that works with assisstive technologies.
 

=======
ISSUE 4
=======

if one is patient (and lucky) enough to find and activate the
quote Can't hear this sound? unquote link, the audio clip doesn't
play using the user agent's default backplane audio rendering engine
(the thing that plays embedded sounds), but, instead, opens whatever
media player one has associated with the filetype being served
client-side; this means that one must manually switch between
applications in order to type as text the contents of the audio
alternative -- a feat complicated by the choice of backwards looping
voices and other background sounds -- into the pertinent field; of
course, every INPUT defined for the FORM should use the LABEL element;

Agreed, I'd like to see the audio embeded. If, for some reason, this fails and we need to have the "can't hear this sound" link, what's the best way to provide the CAPTCHA. One thing that may be hapening is that the headers of the mp3 file have a content disposition asking the user agent to download the file. On linux, without this header, I had problems hearing the audio if my browser wasn't set up properly. I figure that the content-disposition would allow raw access to the file, hopefully the least common denominator for everybody.

[http://www.w3.org/TR/html401/interact/forms.html#h-17.9 ]

i very strongly recommend that the FORM (to whose document source
i cannot get, so i can't make corrections and inline comments) be
placed in a FIELDSET with a LEGEND - consult:


I've attached the html of a captcha area to this email. The html isn't fully complete, because we dynamically insert english strings (we plan to internationalize reCAPTCHA). I've also attached the full, generated html. It may be a bit harder to navigate because it has CSS as well as many extra form elements.

[http://www.w3.org/TR/html401/interact/forms.html#h-17.10 ]
[http://www.w3.org/TR/WCAG10-HTML-TECHS/#forms-grouping]

nor can i overstress the importance of the LABEL element in
contextualizing FORM controls:

[http://www.w3.org/TR/html401/interact/forms.html#h-17.9]
[http://www.w3.org/TR/WCAG10-HTML-TECHS/#forms-labels ]

TABINDEX (determines order through which controls are TAB navigated,
which is VERY helpful when visually one wants the submit control
immediately after the text-entry field, but for which there are
modifiers, assistance mechanisms, or alternatives), which should
be TABINDEX-ed in a logical sequence ENDING with the Submit button:

reCAPTCHA does not control the way the developer makes the page. We only control the area around recaptcha (not even the submit button in general). A representative example is below in my next comment.

We do provide webmasters a way to set the specific tabindex of the reCAPTCHA control. One issue I haven't thought about is the fact we might need multiple tabindex numbers (one for a button, one for a form field). My understanding is that with equal tabindex numbers, the browser will fall back on document order. I think we may ask the developer for one tabindex to allocate to reCAPTCHA and then rely on carefully ordering controls.
 

[http://www.w3.org/TR/html401/interact/forms.html#h-17.11.1 ]
[http://www.w3.org/TR/WCAG10-HTML-TECHS/#forms]

i wish i could have been of more specific assistance to you, but
i could not obtain the actual document source for the reCAPTCHA
form; from what i could obtain of the document source, i would
be wary of including this information in an IFRAME, unless that
is part of the security protocol you are using.

We used the iframe as an easy way to embed the reCAPTCHA control on this specific page. Most pages won't have the iframe. An example URL you can try is:

http://abock.org/2007/05/23/surfing-the-tubes/

One case in which we do use iframes is if the useragent does not have JavaScript. This path is much more difficult to implement, and I'm sure has additional accessibility problems. Once we make the JS version accessible, I'd appreciate your feedback on the non-js path.
 
here are the main accessibility resources cited above, and which
should be implemented in as important a gate-keeper as a CAPTCHA
at Level Triple A compliance to the Web Content Accessibility
Guidelines:
[http://www.w3.org/TR/WCAG10/#Conformance]

 I look forward to meeting these challenges. I believe that reCAPTCHA can be a great asset to those who use assisstive technologies, we are turning image-only books into plain text that can be rendered universally.

My goal is to:
- Ben