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@[10.0.1.2]>
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.

http://lists.w3.org/Archives/Public/wai-xtech/2007Jul/0084.html

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.

Al

>
>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 19:01:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 13:15:43 GMT