Re: reCAPTCHA implementation problems

Hi Ben,

On 14/07/07, Ben Maurer <bmaurer@andrew.cmu.edu> wrote:
<quote>
One issue here though, our controls are all within a table. Using div's
for layout is pretty hard. We're trying to support browsers back to IE
5.0.
</quote>

Although layout tables are very common, and generally don't cause too
many accessibility problems for assistive technology (such as a screen
reader), the table element has a specific role, and isn't intended for
layout. Occasionally, assistive technology announces redundant
information if it incorrectly assumes the layout table is a data
table. The layout of the sample is pretty simple, and IE 5 supports
the div element. The result may not be pixel perfect in IE 5, but
that's probably the least of an IE 5 user's concerns.

Ben wrote:
<quote>
Sadly, we're unable to use tabindex to help us our much. The issue is that
we don't control the entire web page. Most developers don't use tabindex
for their entire form, relying on document order. What we do is allow the
developer to say "please use this tabindex for reCAPTCHA". If they don't
do that, we use document order to lay things out. So we only have one
tabindex item to work with.
</quote>

It is generally better to follow the natural document order, because
as well-intentioned as author-defined tabindex attributes are, they
generally result in an unexpected tab order - particularly after a
couple of updates, and the numbers specified for the tabindex
attribute have been abandoned or have gone out of sequence.

A solution that could work for you would be to put the CAPTCHA on its
own page before or after the valuable resource. That way, you don't
have to worry about anything else the developer has on the page, as
your CAPTCHA would be a gatekeeper for the resource, with minimal
integrations considerations.

Ben wrote:
<quote>
If at all possible, I'd like to get both at the same time. Would non-mouse
users have a browser that highlights accesskey shortcuts to them? We could
put an accesskey on each of the buttons.
</quote>

One of the recognised problems with access keys are their
discoverability. There are tools that can reveal access keys, but
they're not used by the majority of users. There are also suggestions
for standardising access keys for consistency, such as those suggested
by the UK's e-Government Interoperability Framework [1]. You could
make the access key shortcut visible yourself, which would help, but I
imagine that the presentation won't allow that. They could be listed
in the help, but obviously a user would need to be able to get to the
help in the first place.

The best method for *all* users is to allow the items to be navigated
to with a keyboard.

Ben wrote:
<quote>
I think we can make the biggest impact if we can make reCAPTCHA accessible
without degrading the experience for other users.
</quote>

I completely agree, but conventional keyboard access is a fundamental
accessibility requirement. If someone cannot request a new CAPTCHA or
change the method, or get help, then it cannot in any way be
considered accessible. I don't agree with your assumption that
keyboard users don't want to be able to navigate to items on a page,
and allowing them to do so is somehow degrading their experience.

[1] http://archive.cabinetoffice.gov.uk/e-government/resources/handbook/html/2-4.asp#2.4.4


Gez


-- 
_____________________________
Supplement your vitamins
http://juicystudio.com

Received on Saturday, 14 July 2007 09:35:02 UTC