WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: selecting ARIA Tabs and Windows screen readers


From: Birkir R. Gunnarsson
Date: May 23, 2015 3:20PM

I think the differences might be based on whether the tab gets
selected and its associated content loaded into the tabpanel when you
select it with the arrow key, vs. only performing that action when
user has focus on that tab and presses enter.
The ARIA Authoring Practices recommends the former, and Jaws appears
to expect the same, based on the fact that the Jaws shortcut key for
tabs is the same as for comboboxes (well, dropdowns) i.e. pressing "c"
gets you to the next select or tab on a webpage.
This is also the approach we followed when we implemented example tabs
for Deque University:
I am not necessarily sure this is the one and only correct way to
implement tabs. E.g. if each tab panel contains a lot of content it
might slow the browsing experience down a lot when the content for
every tab when keyboard only user is moving the focus to it. If there
are 4 tabs between the currently selected one and the tab the user
wants, the page will refresh 5 times before he gets to it vs. if user
needs to explicitly activate the tab with the keyboard he can naviate
to the desired tab without affecting the page content and only load
the content he is interested in. However, I believe there is no one
right way to do this and it is up to the website. I think eiher
behavior is acceptable.
I have also let tabs go that are not ntested in a tablist and wehre
all the tabs are in focus order. I think this is acceptable if we have
ooonly 2 or 3 tabs on the page. The extra work of implementing arrow
key navigation within a set of 2 or 3 tabs to me just does not seem to
necessarily bring that great benefit to the user. wCAG does not
absolutely dictate how to operate controls with the keyboard, though
the Authoring Practices makes good recommendations.

On 5/22/15, Jennifer Sutton < <EMAIL REMOVED> > wrote:
> Greetings, WebAIM:
> I'm testing some ARIA tabs, and I am getting different behavior when
> using JFW 15 and IE 11 and JFW 15 and FF 36.
> I've seen so many different implementations of ARIA tabs that I need
> to confirm my expectations.
> Before everyone says: "just use NVDA," I'm about to test that, too,
> but end-users are likely to be using JFW, so I need to test with that.
> I'm getting different results with these combinations, and I'm not
> sure whether it's the code or the AT. So . . .
> Does anyone have a sample of ARIA Tabs that they feel is implemented
> correctly, so I can compare that with my test case?
> I'm imagining VO for the Mac would function similarly; I'm only
> concerned about the desktop experience.
> This is a very simple set of two ARIA tabs only. I don't want lists
> or headings involved, if possible.
> I can hear that a tab is initially selected by default (and
> identified as such), and when I hit enter on the second one, I go
> into forms mode. And while I can then use up and down arros to move
> between the two, when I use escape to exit forms mode (when on the
> tab I want to choose), sometimes it shows as selected, and sometimes
> it doesn't. And I don't get selection feedback when in forms mode
> and moving between the two tabs. I'd think JFW should be able to
> report that, but perhaps I'm incorrect.
> I believe these are vertical tabs, so using up and down arrow (rather
> than right and left for horizontal ones) does seem correct in this case.
> I've got plenty of examples of code; it's confirmation of screen
> reader user expectations I need. And maybe there are browser issues I
> need to watch out for, but ARIA tabs have been around for a long
> time, so I'm hoping not.
> When these two tabs are tested with keyboard-only (no screen reader),
> they do operate correctly.
> Thanks, and happy long weekend to all in the U.S.
> Best,
> Jennifer
> > > > >

Work hard. Have fun. Make history.