E-mail List Archives
Thread: ARIA tabs interaction
Number of posts in this thread: 10 (In chronological order)
From: Joseph Sherman
Date: Thu, Apr 28 2016 8:29AM
Subject: ARIA tabs interaction
No previous message | Next message →
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
From: Detlev Fischer
Date: Thu, Apr 28 2016 10:13AM
Subject: Re: ARIA tabs interaction
← Previous message | Next message →
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
>
> > > > >
From: Bryan Garaventa
Date: Thu, Apr 28 2016 11:43AM
Subject: Re: ARIA tabs interaction
← Previous message | Next message →
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 ADDRESS REMOVED =
415.624.2709 (o)
www.SSBBartGroup.com
From: Lucy Greco
Date: Thu, Apr 28 2016 12:01PM
Subject: Re: ARIA tabs interaction
← Previous message | Next message →
from the user prospective if you let the tab key be used the user may not
know witch tab is selected in the end its key to not use the tab key so
that the user can be sure the last interaction with the tab selection is
there choice let me give a sample in the gmail settings tabs let you tab
through them. as you tab throu the tab itself is selected. the user finds
the settings pannal they want and then they keep tabbing and dam if it does
not chage the selected tab so in this sinarryo the user needs to figure
out how the hell to pick the second tab and then skip over the rest of the
tabs and move to the contents of the tab if these were just aero selectable
tabs that problem would not happen
Lucia Greco
Web Accessibility Evangelist
IST - Architecture, Platforms, and Integration
University of California, Berkeley
(510) 289-6008 skype: lucia1-greco
http://webaccess.berkeley.edu
Follow me on twitter @accessaces
On Thu, Apr 28, 2016 at 10:43 AM, Bryan Garaventa <
= EMAIL ADDRESS REMOVED = > 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 ADDRESS REMOVED =
> 415.624.2709 (o)
> www.SSBBartGroup.com
>
>
>
From: Joseph Sherman
Date: Thu, Apr 28 2016 12:34PM
Subject: Re: ARIA tabs interaction
← Previous message | Next message →
Right, if the Tab key changes the menu Tabs AND goes through the Tab/menu items that can definitely be a pain to navigate.
Joseph
From: Morten Tollefsen
Date: Fri, Apr 29 2016 1:51AM
Subject: Re: ARIA tabs interaction
← Previous message | Next message →
Bryan, I agree, and "best practise using arrow keys" is known from native software (panes in Windows, OSX, ...). If users are confused here, I do believe this is because it is extremely easy to find bad implementations.
BR: Morten Tollefsen
+47 90899305, www.medialt.no
-----Opprinnelig melding-----
Fra: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] På vegne av Bryan Garaventa
Sendt: torsdag 28. april 2016 19.44
Til: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Emne: Re: [WebAIM] ARIA tabs interaction
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 ADDRESS REMOVED =
415.624.2709 (o)
www.SSBBartGroup.com
From: _mallory
Date: Fri, Apr 29 2016 2:45PM
Subject: Re: ARIA tabs interaction
← Previous message | Next message →
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 ADDRESS REMOVED =
> 415.624.2709 (o)
> www.SSBBartGroup.com
>
>
>
From: Jim Allan
Date: Fri, Apr 29 2016 3:23PM
Subject: Re: ARIA tabs interaction
← Previous message | Next message →
+1
On Fri, Apr 29, 2016 at 3:45 PM, _mallory < = EMAIL ADDRESS REMOVED = > wrote:
> 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 ADDRESS REMOVED =
> > 415.624.2709 (o)
> > www.SSBBartGroup.com
> >
> >
> >
From: Bryan Garaventa
Date: Fri, Apr 29 2016 5:01PM
Subject: Re: ARIA tabs interaction
← Previous message | Next message →
I get the frustration, yet a lot of what is experienced from the points you mention have to do with non-intuitive design and unreliable scripting.
For example: The use of ARIA Tab attributes simply effects the mapping in the accessibility tree, it has no effect on the scripting or visual layout of the page.
For sighted keyboard only users, a designer can add a simple CSS class like the following to visually display arrows to indicate that the arrow keys should be pressed when interacting with a particular group of elements.
*[role="tab"]:focus:after {
/* style using content to display arrows here when focused */
}
Typically this isn't needed if groups are visually conveyed intuitively, but this is an option that developers have at their disposal.
I agree that icons without textual equivalents is a problem, and the same technique can be used to do the same thing actually, to accompany attributes such as aria-label that are not rendered visually.
E.G
<span aria-label="Add Favorite" class="addIcon" role="button" tabindex="0"></span>
The following CSS will then display the above aria-label text for both sighted mouse and keyboard only users.
span.addIcon:focus:after, span.addIcon:hover:after {
/* Rules to position pseudo element. */
content: attr(aria-label);
}
Nothing is ever perfect, but we all have to move forward, and saying that it's impossible for people to learn, will never help this happen.
Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
= EMAIL ADDRESS REMOVED =
415.624.2709 (o)
www.SSBBartGroup.com
From: _mallory
Date: Mon, May 02 2016 3:18AM
Subject: Re: ARIA tabs interaction
← Previous message | No next message
On Fri, Apr 29, 2016 at 11:01:23PM +0000, Bryan Garaventa wrote:
> I get the frustration, yet a lot of what is experienced from the points you mention have to do with non-intuitive design and unreliable scripting.
>
> For example: The use of ARIA Tab attributes simply effects the mapping in the accessibility tree, it has no effect on the scripting or visual layout of the page.
At work we currently have a product used by many where someone did
indeed take a tabby-panel type thing, added a bunch of ARIA roles,
but then did not also add in all the keyboarding as per the ARIA
authoring practices spec-- the worst of both worlds, and I've
seen a lot of that around too.
Right now I'm debating whether I will make them keep the current
working and remove the roles (there are only three tabs so it's
not the keyboarding nightmare some aria-less tab panels can be),
or keep the roles, add in the appropriate keyboarding, and then
try to let all the users know why their tabs broke. Even screen
reader using users won't initially know how to use them without
some instruction, since now JAWS is all confused when it sees
the roles and tries to tell people to "hit space to select"
or whatever.
>
> For sighted keyboard only users, a designer can add a simple CSS class like the following to visually display arrows to indicate that the arrow keys should be pressed when interacting with a particular group of elements.
>
> *[role="tab"]:focus:after {
> /* style using content to display arrows here when focused */
> }
That's an idea.
>
> Typically this isn't needed if groups are visually conveyed intuitively, but this is an option that developers have at their disposal.
>
> I agree that icons without textual equivalents is a problem, and the same technique can be used to do the same thing actually, to accompany attributes such as aria-label that are not rendered visually.
>
> E.G
>
> <span aria-label="Add Favorite" class="addIcon" role="button" tabindex="0"></span>
>
> The following CSS will then display the above aria-label text for both sighted mouse and keyboard only users.
>
> span.addIcon:focus:after, span.addIcon:hover:after {
> /* Rules to position pseudo element. */
> content: attr(aria-label);
> }
I've done similar with the title attributes added to (actual) buttons
on the Discourse software in my browser's user CSS. If sites used
something consistently like titel or aria-label, I could even go from
site to site and know what all those silly buttons do!
>
> Nothing is ever perfect, but we all have to move forward, and saying that it's impossible for people to learn, will never help this happen.
It's not that people can't learn, it's more that it seems several
don't seem to realise that, unlike some of the truly newer things
showing up on web sites (sliders that actually work with keyboard
at all for example, or autocomplete), people have been trained on tab
panels already-- so in this case it's not just people learning a new
thing, but they also need to unlearn an old thing.
And I still want text above every one that's different, partially
also because the older sites out there who were built back when
the CSS "Sliding Doors" technique was the main way people styled
links to look like paper folder tabs are not being updated (it will
take a lot of time for them to get replaced. I expect replacement
is more likely than code updates, since these old pages definitely
breathe "old" and people like replacing everything with, I dunno,
Bootstrap). Meaning, the old way will coexist for quite a while with
the new way. This makes "teaching" people even harder.
_mallory