Re: reCAPTCHA implementation problems

Hey Gregory,

On Fri, 13 Jul 2007, Gregory J. Rosmaita wrote:
> the only objects in the tab navigation order (using JAWS6,
> JAWS6.10, JAWS7, and the latest release, JAWS 8.0.2107) was
> the edit box and the submit button -- trying NVDA, i had an
> identical experience: i could not tab-to the 3 alternate
> options, which -- as gez pointed out -- still don't have
> alternative text, but are still identified by their filename,
> as was the case when i first contacted the reCAPTCHA project
> in may;

Oh wow, I'm really stupid. We botched up the alt text addition. Here's 
what happened. Our code looked like this before:

     $('recaptcha_switch_audio_btn').href = 
"javascript:Recaptcha.switch_type('audio');";
     $('recaptcha_switch_audio_btn').title = $_.audio_challenge;

recaptcha_switch_audio_btn is the <a> element around the <img>. So I 
wanted to add an alt tag. What do I do:

     $('recaptcha_switch_audio_btn').alt = $_.audio_challenge;

Which just set a field of the <a> element in the DOM

Colin -- could you fix this up and push it please :-).

> like gez, the only way i could access the three options via
> the keyboard was to use the JAWS-generated "list of links" or
> the JAWS-generated "list of graphics", as the 3 graphically
> demarcated pseudo-button links are NOT included in the
> JAWS-generated "form control list"

So we should probably look into using an element that is more button-like. 
Is tab index still going to be an issue here -- we still want to set 
tabindex to -1 for visual browsers because it makes more sense in that 
case.

> the most important thing to communicate to you about the graphical
> options is simply this: had i not known they were there, i may
> have never even discerned them, since they don't appear where a
> user would expect them to appear -- as part of the form's
> tab-order or listed in a list of form fields...  so there are 2
> problems here:
>
> 1. user doesn't know what to expect when encountering the form
>
> 2. user may never discern that the graphical tier of alternate
> slash assistance links even exist, eliminating (or limiting)
> the likelihood that a user will use JAWS' virtual cursor to
> inspect the entire page, nor should they be expected to be able
> to read document source in order to simply discover their
> existence...
>
> quick and dirty fix: since the form is contained in a table, have
> you given any thought to adding a brief description of the form
> (how many fields, the tab order, that an audio alternate is
> available, etc.) -- using a summary would greatly assist a
> non-visual user in conceptualizing the form, rather than leave
> the user with the mistaken impression that there are only 2
> navigatable controls in the form, the edit box and the submit
> button...  (still like to put it in a fieldset, form or no, but
> first things first)

I like the idea of having some sort of summary for non-visual users. What 
is the best way to add some text as a summary to screan readers? Ideally 
we'd like to include a link to more detailed help with screen readers.

Obviously though, we need to fix some of the underlying issues too. I 
don't want to just through up some text saying "Hey, if you're using a 
screen reader, this form is complex. Have fun :-)"

> is one of the difficulties you've encountered associating alt
> text with specific graphical items inserted into the page
> instance by javascript?

It seems that stupidity was the major issue there ;-(.

-b

Received on Friday, 13 July 2007 18:47:08 UTC