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

At 10:56 PM +0100 13 07 2007, Gez Lemon wrote:
>Hi Ben,
>
>On 13/07/07, Ben Maurer <bmaurer@andrew.cmu.edu> wrote:
>
><quote>
>So we should probably look into using an element that is more button-like.
>Is tab index still going to be an issue here -- we still want to set
>tabindex to -1 for visual browsers because it makes more sense in that
>case.
></quote>
>
>A tabindex attribute value of -1 will be a serious accessibility
>issue, regardless of the type of browser you're targeting. A value of
>-1 takes the control (link, button, or anything else that could
>receive focus) out of the tab order, which means it cannot be accessed
>by people using the keyboard. That won't just effect screen reader
>users, but anyone who is unable to use a pointing device. If you want
>to ensure the widget is accessible, then any links or buttons must be
>accessible with a keyboard.

Agreed.  There aren't two cases (screen-reader and point-and-click).
There are multiple cases, and plenty of visual, no-mouse users.

>The only time a tabindex attribute value of -1 is appropriate is if
>you definitely do not want people to be able to navigate to the
>element with the keyboard, but need to be able to programmatically
>focus on the element

Not exactly:  in WAI-ARIA widgets we use TABINDEX='-1' where the
element is still keyboard navigable, but * not in the TAB sequence. *
Other keys such as arrows are used inside familiar widgets, enabled
by code in the widget scripting. So the TAB sequence takes you
through a navigation outer loop, augmented by inner loops here and
there where familiar widgets have their own internal navigation keys
other than TAB for local navigation.

<sample
cite="http://www.mozilla.org/access/dhtml/tree">
<div tabindex="-1" role="wairole:treeitem">Bananas</div>
</sample>

[You don't see the TABINDEX value in the HTML examples because
it is written into the DOM by the enable.js scripts]

In this coding style "keyboard navigable" and "TAB navigable" are no
longer synonymous.

At least that is how I understand it.  I'm just learning.  But I 
believe that this
is what screen reader users are familiar with from desktop 
(installed) applications.

Al

>- this isn't the case here. Requesting a new
>CAPTCHA, toggling between visual and audio CAPTCHAs, and getting help
>are essential functions that everyone should be able to access, so
>those elements must be available with the keyboard alone to be
>considered accessible.
>
>Cheers,
>
>Gez
>
>--
>_____________________________
>Supplement your vitamins
>http://juicystudio.com

Received on Saturday, 14 July 2007 14:17:21 UTC