- From: David Poehlman <poehlman1@comcast.net>
- Date: Fri, 13 Jul 2007 12:33:01 -0400
- To: joshue.oconnor@cfit.ie
- Cc: "Gregory J. Rosmaita" <oedipus@hicom.net>, Gez Lemon <gez.lemon@gmail.com>, Ben Maurer <bmaurer@andrew.cmu.edu>, wai-xtech@w3.org
The virtual cursor is different from the jaws cursor and one of the first things new users learn and is used quite often by users but should not have to be used to find controls. I don't agree though that a summary would be all that helpful since most screen readers can now provide that on demand and since it would ad more clutter to the page. On Jul 13, 2007, at 12:25 PM, Joshue O Connor wrote: Gregory J. Rosmaita wrote: > 1. user doesn't know what to expect when encountering the form Exactly, and also if this CAPTCHA is going to be different from the way the usual CAPTCHA will work (or not) then the user will have to be informed of such. The skillful use of @summary in this case would be really good. > 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, [...] Relying on the user to be able to navigate their way around using the JAWS cursor is a bridge too far (in my book) as it is usually something that only power users, or at least rather experienced screen reader users will ever do so IMO it is not ideal to rely on it for the user to find - what is essentially to be core functionality - of the accessible CAPTCHA. > 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 [...] Agreed. The switch to audio button could be a graphic with suitable alt text that describes to the user what it is for. This would enable it to have focus when the user tabs to it. Is it because of the way Javascript has been applied in this instance that the two buttons 'reload' and 'switch type' are both somehow out of the tab order? If so would it be possible to use an element that would stay in the tab order and still be able to call a JS function to trigger the switch to audio mode? I guess so. I also noticed a huge amount of 'vertical bars' in the interface, which are really tedious to listen to, did anyone else get that? Or is it indicative of my ongoing driver issues while running JAWS with Parallels on a Mac Book Pro :-( Josh -- Jonnie Appleseed With his Hands-On Technolog(eye)s reducing technology's disabilities
Received on Friday, 13 July 2007 16:33:43 UTC