- From: Chris Blouch <cblouch@aol.com>
- Date: Tue, 17 Jul 2007 13:45:49 -0400
- To: Alfred.S.Gilman@IEEE.org
- CC: wai-xtech@w3.org, Colin McMillen <mcmillen@cs.cmu.edu>
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 Tuesday, 17 July 2007 17:46:16 UTC