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

The pattern as described needs one caveat:
For widgets that themselves can accept the Tab as input (think rich text area), Ctrl+Tab would be used to move focus beyond that widget.

-Lisa 

> -----Original Message-----
> From: wai-xtech-request@w3.org 
> [mailto:wai-xtech-request@w3.org] On Behalf Of Chris Blouch
> Sent: Tuesday, July 17, 2007 1:46 PM
> To: Alfred.S.Gilman@IEEE.org
> Cc: wai-xtech@w3.org; Colin McMillen
> Subject: Re: [note: two-level nav in WAI-ARIA] [was: Re: 
> reCAPTCHA implementation problems]
> 
> 
> With a few exceptions the accessible widget models seem to 
> follow a pattern where you tab to the widget, use other keys 
> to navigate within the widget (arrows, space etc) and a 
> second tab takes you out of the widget. Is this the generally 
> accepted practice we want to promote? 
> Seems to align well with the GUI pattern of select an object, 
> manipulate it and then release it.
> 
> CB
> 
> Alfred.S.Gilman@IEEE.org wrote:
> >
> > 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 Wednesday, 18 July 2007 01:53:31 UTC