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

Re: [note: two-level nav in WAI-ARIA] [was: Re: reCAPTCHA implementation problems]

From: Gez Lemon <gez.lemon@gmail.com>
Date: Wed, 18 Jul 2007 04:04:14 +0100
Message-ID: <e2a28a920707172004jca81e2au6707b57f5216d33b@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 13:15:43 GMT