- From: Gez Lemon <gez.lemon@gmail.com>
- Date: Wed, 18 Jul 2007 04:04:14 +0100
- To: "Ben Maurer" <bmaurer@andrew.cmu.edu>
- Cc: "Al Gilman" <Alfred.S.Gilman@ieee.org>, "Chris Blouch" <cblouch@aol.com>, wai-xtech@w3.org, "Colin McMillen" <mcmillen@cs.cmu.edu>
Hi Ben, On 18/07/07, Ben Maurer <bmaurer@andrew.cmu.edu> wrote: > Please don't get me wrong, I want to make reCAPTCHA as accessible as > possible. Then regardless of what anyone has said in this thread, keyboard accessibility to primary content is essential. > However, when a11y changes also change behavior for other users, > we obviously need to evaluate that much more carefully. If the change > doesn't work as well for the majority of our users, we'll look for ways to > fix the issue. All users (people with and without disabilities) should be able to navigate to primary content using the keyboard alone, The expected behaviour to navigate to primary interface elements is using the tab key. Removing primary interface elements from the tab order is a huge usability mistake for all users. As I mentioned in an earlier response, those wanting to submit the form without having to navigate through other links/buttons to get to the submit button would merely press return having filled in the last piece of data (the CAPTCA itself in the examples you posted). > Should no workarounds be available, we'll have to balance > the impact on the general population with exactly what features would be > made less accessible (for example, for a visual user, disabling the three > buttons on the side isn't the end of the world, they can still solve the > CAPTCHA). People with some types of mobility problem are unable to use a pointing device. It might not be the end of the world, but it's highly likely that these people will be denied access to resources because they are unable to change the image to a more recognisable image, or change the method of CAPTCHA (for example, people with mobility problems who also have vision impairments, but not to the extent that they rely on very expensive assistive technology). Taking primary content out of the natural tab order is a serious accessibility issue. > About keyboard navigation specifically -- as you mention, it's obvious > that having the tab order include EVERYTHING in the document isn't ideal. Please allow me to clarify that point. Al was referring to rich interface elements, such as a tree control, where a user would want to be able to use the tab key to navigate to each tree control, but wouldn't want the tab key to navigate through all branches and leaves on tree controls, as it would be too cumbersome. So, for example, a developer might enable the branches to be expanded/collapsed using the right/left cursor keys, and to traverse through the leaves using the up/down arrow keys. The cursor keys are the controller, and the script that enabled that functionality is providing the programmatic access, which is where a tabindex attribute value of -1 is appropriate, as it means those items don't have to be navigated through by keyboard users, making the process ridiculously cumbersome. Your example includes links or buttons, which are primary interface elements that should be available using the tab key. It is ideal that those elements are included in the tab order. You suggested doing user-testing - please do, as it will become apparent that it's essential those items are keyboard accessible. Also, unlike Al's example, you have no intention of making those accessible with other keystrokes (and neither should you, as it would be unexpected behaviour in this case). > Tabs should go through logical components with second level navigation > available. Links and/or buttons are not secondary navigation items - secondary navigation items include sub-menus, nodes in a tree control, and so on. Links and buttons are primary interface elements. If those links/buttons cannot be used to request a new challenge, change the type of challenge, or get help, then the whole system is inaccessible. > Until better browser support is available to do this, we need > to figure out a work around. The one's I've seen so far are: > > - "screw it" let's put everything in the tab order > - Pro: accessible to everybody > - Cons > - May not be ideal for the majority of the population > - Potentially confusing tab order (reCAPTCHA is very > limited due to the constraint of living in the author's > document) In this case, this isn't a "screw it" approach – the links/buttons are primary interface elements that must be keyboard accessible. > - Access keys > - Pro: invisible to normal users > - Con: depends on the UA for exposure. Could conflict with primary > site. I don't know what you consider to be a "normal user", but I'm struggling to imagine anyone that wouldn't want to be able to navigate to items on a web page using the keyboard. Al was talking about extending functionality for rich interface elements so that they are accessible with a keyboard, whereas you're talking about removing keyboard accessibility for everyone - that is an accessibility problem. Gez -- _____________________________ Supplement your vitamins http://juicystudio.com
Received on Wednesday, 18 July 2007 03:04:20 UTC