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...
For further actions, you may consider blocking this person and/or reporting abuse
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
tablistthe 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
SpaceorReturn.However, in both of those, the whole tab bar is a single
Tabtarget, as in "you focus the whole thing and the nextTabpress takes you out of it entirely".Sort of like if it was a slider
inputor 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 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...
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?
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;
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? 😅
Great post Andrew, thank you!
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.
Fixed