WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: ARIA tabs interaction

for

From: _mallory
Date: Apr 29, 2016 2:45PM

This is already the problem. Tabs worked for sighted keyboarders,
but now they don't.

Honestly, whenever some committee decides to change how the web
has traditionally does things, it should insist that all developers
who do this add visible plain-text for all of us telling us the
new way of doing things. I suck as badly at guessing the new
unicorn keystrokes that will now work as much as I suck at
guessing what the squiggly eyeball icon with no label text means.

Because on the web, this is a very new, and different, way of
doing things. Sighted people are not psychic. The web doesn't
act like desktop. Mousers don't double-click there. Things styled
with CSS to emulate fake tabs have traditionally been anchors,
and anchors can be tabbed to with tab. Or so we have been tricked
to believe in the past.

I kinda wish I could force everyone to watch real humans slowly
curse at their keyboards and wonder why they had to be unlucky
enough to be born too stupid to figure out how to use a computer
whenever they run across these things. It will break your hearts.

_mallory

On Thu, Apr 28, 2016 at 05:43:46PM +0000, Bryan Garaventa wrote:
> The danger of this logic being, if everybody does this differently, nobody will ever understand what is expected now or in the future.
>
>
> Bryan Garaventa
> Accessibility Fellow
> SSB BART Group, Inc.
> <EMAIL REMOVED>
> 415.624.2709 (o)
> www.SSBBartGroup.com
>
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Detlev Fischer
> Sent: Thursday, April 28, 2016 9:14 AM
> To: <EMAIL REMOVED>
> Subject: Re: [WebAIM] ARIA tabs interaction
>
> The best practice (to use arrow keys within tab lists for focuusing tabs) has always be conceptually difficult as there is no clear conceptual separation of tabbed navigation areas where you expect tabbing to work, and tab-panel like structures where (accorfding to ARIA best practices) arrow keys should be used. That is why many developers chose to support tabbing to tabs nad you find very different implementations with variants regarding the use of ARIA. For menus proper, i.e. the Menubar widget that really implement an application pulldowen menu like https://hanshillen.github.io/jqtest/#goto_menubar the situation is different.
>
> So to answer the question, I personally don't see it as wrong to allow the user to tab through the top-level menu items, certainly niot for navigation menus, and I I see definite usability advantages of supporting both arrowing and tabbing for tabs in tab panels even if this deviates from ARIA best practice.
>
> Detlev
>
> --
> Detlev Fischer
> testkreis c/o feld.wald.wiese
> Thedestr. 2, 22767 Hamburg
>
> Mobil +49 (0)157 57 57 57 45
> Fax +49 (0)40 439 10 68-5
>
> http://www.testkreis.de
> Beratung, Tests und Schulungen für barrierefreie Websites
>
> Joseph Sherman schrieb am 28.04.2016 16:29:
>
> > The design guide for ARIA menu tabs uses the "Tab" key to get into the
> > tabs list, and then the arrow keys to move through the menu tabs and
> > menu items. In my experience users, especially without a screen
> > reader, expect the "Tab" key to move to the next menu Tab and are
> > confused when the "Tab" key skips the menu tabs. Is it "wrong" to
> > follow the guide but allow the user to tab through the top-level menu items?
> >
> >
> > Joseph
> >
> > > > > > archives at http://webaim.org/discussion/archives
> > > >
>
> > > > > > >