- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Sat, 14 Jul 2007 10:17:06 -0400
- To: wai-xtech@w3.org
- Cc: "Colin McMillen" <mcmillen@cs.cmu.edu>
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