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, t... [Read Full]
markdown guide
 

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.

 

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

 

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.

 

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?

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.

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.

 

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?

 

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 🙂

 

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

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

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.

 

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?

 
code of conduct - report abuse