reCAPTCHA implementation problems: advice and reply [FWD]

in retrospect, i should have copied this thread to either www-archive or 
wai-xtech, those being public archives...  wai-liaison is member access 
only, so i am forwarding this to XTech in order that all of us working 
on all of the aspects of accessibility can contribute to what will be 
the pre-packaged CAPTCHA challange:

---- FIRST MESSAGE IN THREAD ----
Date: Fri, 25 May 2007 15:01:21 -0400   
From: "Gregory J. Rosmaita" <oedipus@hicom.net>      
To: info@recaptcha.net,support@recaptcha.net
CC: wai-liaison@w3.org
Subject: implementation problems with the reCAPTCHA audio alternative
   
this emessage refers to the FORM contained in the IFRAME 
located at: 
[http://recaptcha.net/fastcgi/demo/recaptcha] 

there are 4 major accessibility issues with the reCAPTCHA
FORM template, which MUST be addressed as soon as possible, 
so that those who NEED the alternative audio can actually 
locate and access the alternative audio -- currently, the 
link to the audio alternative has no alternative text 
associated with it, and in the world of aural web browsing 
(browsing with a screen reader, as i am) if an image 
doesn't have a text equivalent, it doesn't make any noise, 
no matter how close to you the metaphoric tree falls. 

======= 
ISSUE 1 
======= 

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 

======= 
ISSUE 2 
======= 

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; 

[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] 

======= 
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; 

======= 
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; 

[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: 

[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: 

[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. 

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] 

Web Content Accessibility Guidelines, version 1.0 
[http://www.w3.org/TR/wcag10/] 
WCAG1 Techniques: 
[http://www.w3.org/TR/WCAG10-TECHS/] 

Web Content Accessibility Guidelines, version 2.0 (working draft): 
[http://www.w3.org/TR/2007/WD-WCAG20-20070517/] 
WCAG2 Techniques: 
[http://www.w3.org/TR/WCAG20-TECHS/] 
[http://www.w3.org/TR/2007/WD-WCAG20-20070517/] 

please feel free to contact me if you want to discuss this urgent 
matter further; my eddress is <oedipus@hicom.net> 

thank you, 
gregory j. rosmaita 
---------------------------------------------------------- 
ACCOUNTABILITY, n. The mother of caution. 
                -- Ambrose Bierce, The Devil's Dictionary 
---------------------------------------------------------- 
        Gregory J. Rosmaita, oedipus@hicom.net 
     Camera Obscura: http://www.hicom.net/~oedipus/ 
UBATS-United Advocates for Talking Signs: http://ubats.org 
---------------------------------------------------------- 


--------- SECOND MESSAGE IN THREAD -- REPLY FROM reCAPTCHA --------
From: "reCAPTCHA Support" <support@recaptcha.net>
To: "Gregory J. Rosmaita" <oedipus@hicom.net>
Cc: wai-liaison@w3.org
Sent: Fri, 25 May 2007 18:04:41 -0700
Subject: Re: implementation problems with the reCAPTCHA audio alternative

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:

   - Over the weekend
      - Fix stupid mistakes (such as the alt text)
      - Fully read up on the accessibility documents you sent me
   - Over the next week
      - Try to implement a tab ordering that makes sense for
      non-visual browsers
   - Within two weeks
      - Sit down with a user using assisstive technology and observe
      them use reCAPTCHA

- Ben
------- End of Forwarded Message -------