W3C home > Mailing lists > Public > wai-xtech@w3.org > July 2007

Re: reCAPTCHA implementation problems

From: Gez Lemon <gez.lemon@gmail.com>
Date: Fri, 13 Jul 2007 10:06:59 +0100
Message-ID: <e2a28a920707130206l1e1fb699i88048b3a2ac6111@mail.gmail.com>
To: "Ben Maurer" <bmaurer@andrew.cmu.edu>
Cc: "Gregory J. Rosmaita" <oedipus@hicom.net>, wai-xtech@w3.org

Hi Ben,

On 12/07/07, Ben Maurer <bmaurer@andrew.cmu.edu> wrote:
I'd love to hear comments about how the different screen reading
products handle Javascript. As was mentioned in my reply to Gregory,
when working with T.V. Raman on his windows computer, we found that
the screen reader didn't see the javascript generated content (despite
the fact that Javascript was actually executing, as I could see on the
visual copy of the page). T.V. mentioned that he was unfamiliar with
the Windows screen reading technology, and that he wasn't sure what
the issue was.

Some screen readers, such as JAWS, take a snapshot of a web page when
it's loaded so that they can use their own cursors to allow users to
interact with the content. The snapshot usually isn't updated until a
navigate event is raised, although there is usually a command that
screen reader users can use to update the snapshot (Insert+ESC in
JAWS). If the script doesn't raise a navigate event (such as loading a
dummy resource in a hidden IFrame), then the screen reader won't know
of the new content without the screen reader user becoming suspicious
that something should have happened and refreshing the view

Looking at the example page [1], I couldn't work out how to access the
"Get new challenge", "Get audio challenge", and "Help" links using the
keyboard alone.

[1] http://recaptcha.net/fastcgi/demo/recaptcha



Supplement your vitamins
Received on Friday, 13 July 2007 13:44:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:51:33 UTC