DEV Community

Cover image for Accessibility first: tabs

Accessibility first: tabs

Andrew Bone on January 29, 2019

I've decided to pick up this series for another element. I was inspired by @lkopacz's post on accessibility and javascript, it's worth a read, to m...
Collapse
 
darcyrayner profile image
Darcy Rayner • Edited

Great article! My one nitpick, is overriding the left/right keys to cycle the tabs going to be annoying for some users? For instance, Voice Over on Mac uses left/right to cycle through all the page content, so a user might reasonably expect that the open tab would stay selected until they explicitly changed it. Having said that, I haven't done testing with blind users to find out what their preferences are.

Collapse
 
link2twenty profile image
Andrew Bone • Edited

Once you tab past the tablist the left and right key start working as normal.

It's actually part of the aria spec to do so, which is why I included it. But different users may feel differently about it.

w3.org/TR/wai-aria-practices/examp...

Do you think I should include a link to this in my keyboard support section?

EDIT: I've added a reference to the w3 page now

Collapse
 
darcyrayner profile image
Darcy Rayner

That makes a lot of sense actually. There are so many websites with poor accessibility, I often wonder how that has impacted user expectations and if they differ from the standards.

Collapse
 
qm3ster profile image
Mihail Malo

Yeah, it was incredibly weird for me too.
I'd expect them to maybe change the focused tab, but not actually activate it?
How do I read the tab title without activating it?

Thread Thread
 
link2twenty profile image
Andrew Bone

You can use the tab key to move only the focus, which will read the tab title and tell you whether it's active or not. Then you can press either space or return to activate that tab.

Thread Thread
 
qm3ster profile image
Mihail Malo

Sorry, I was also referring to the examples at w3.org.
The one you linked as These keyboard requirements can be found here was Example of Tabs with Automatic Activation, but there was also Example of Tabs with Manual Activation where indeed you need to press Space or Return.
However, in both of those, the whole tab bar is a single Tab target, as in "you focus the whole thing and the next Tab press takes you out of it entirely".
Sort of like if it was a slider input or something of the sort.

Collapse
 
qm3ster profile image
Mihail Malo

Using roles instead of classes as the CSS/JS selector to not forget to apply the role AND not have an extra class is a really nice touch, bravo.
Did you arrive at that yourself or see it somewhere before?

Collapse
 
link2twenty profile image
Andrew Bone

I think it's relatively common practice these days, I didn't explicitly learn it from someone/something but I may have picked it up somewhere 🙂

Collapse
 
qm3ster profile image
Mihail Malo

Guess I rarely if ever see the source of accessible sites. 😨

Thread Thread
 
link2twenty profile image
Andrew Bone

Unfortunately, accessibility has become an afterthought for lots of people but I think, hope really, that that is really starting to change 😀.

Thread Thread
 
qm3ster profile image
Mihail Malo

Yeah, I'm sure it's on the way up, and at a historical high actually.
The only time pages were more parseable than now would be when they were truly formatted like documents and table layouts didn't take off yet.
But then there were neither accessibility tools to make use of it, nor semantically meaningful HTML5 attributes, nor additional attributes for accessibility.
So yeah, I don't agree with the "accessibility has become an afterthought" statement. It is still an afterthought for many end developers, such as small businesses, but frameworks and component libraries are doing an unprecedented good job of making it easy and even automatic to be accessible.

Collapse
 
harishkalaga profile image
harishkalaga

I understand this, but I feel the tabs should not be tabbable in the beginning, only the tab which is active should be tabbable, the other tabs should be toggled by using arrow keys. Only the active tab should be tabbable, and the tabpanel associated with it should be tabbable.
'role' tabs all of them should have tabindex -1 other than the one which is active.
The other tabpanel can have tabindex 0 but they should be hidden, and upon user interaction to the tab they should be visible.
Reference: w3.org/TR/wai-aria-practices/examp...

Collapse
 
scoutie12 profile image
scoutie12

I'm using 3 tabs for a conference agenda, when toggled will show the agenda for a specific day of the week. The agenda for each day can be quite long and in all of the examples I see it just shows one paragraph. After I select a tab I don't seem to be able to use the down arrow to scroll down the page. Is this a bad use of tabs?

Collapse
 
afozbek profile image
Abdullah Furkan Özbek

I am also inspired from @lkopacz . She writes wonderfull article 😍 so that I am also write about how to create accessible tablists . Altough I write the article in Turkish. You can find that here;

Collapse
 
kallaugher profile image
Alice Kallaugher

Interesting post, thank you! My only followup question: my interpretation of the w3 keyboard support guidelines is that if a tab in the tablist is in focus, the tab key should move focus to the tab panel itself, instead of moving the focus to the next tab in the tablist. What do you think?

Side note -- how many times can I use 'tab' in a single sentence? 😅

Collapse
 
rhymes profile image
rhymes

Great post Andrew, thank you!

Collapse
 
lperamo profile image
Lionel Péramo

There is an error in the keyboard requirements section. The goal of Home key and End key are inverted. Home key is for the first tab and End key is for the last tab.

Collapse
 
link2twenty profile image
Andrew Bone

Fixed