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: Al Gilman <Alfred.S.Gilman@IEEE.org>
Date: Tue, 17 Jul 2007 15:00:56 -0400
Message-Id: <p06110433c2c2bfe2b55e@[]>
To: Chris Blouch <cblouch@aol.com>
Cc: wai-xtech@w3.org, Colin McMillen <mcmillen@cs.cmu.edu>

At 1:45 PM -0400 17 07 2007, Chris Blouch wrote:
>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.

That is the proposed practice that the WAI-ARIA design is predicated on.

That does not necessarily equate to "generally accepted." It's an
innovation on the Web. I don't yet know if Josh had read my post and
rejected it, or was simply saying 'amen' to the message I replied to,
without having considered this alternative.


The premise of the PFWG adoption of this two-level navigation in
WAI-ARIA is that it will significantly shorten the TAB list. This
could be an important benefit; as otherwise the TAB list is at risk of
becoming unworkably long. We are expecting that the user will be able
to navigate inside the widget because the widget local-navigation
keys are mostly familiar from dealing with the GUI interfaces of
installed applications.


>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:
>>>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
>>>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.
>><div tabindex="-1" role="wairole:treeitem">Bananas</div>
>>[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.
>>>- 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.
>>>Supplement your vitamins
Received on Tuesday, 17 July 2007 19:01:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:51:33 UTC