I’ve said before one quick and powerful thing you can learn as a front-end developer just getting starting with JavaScript is changing classes.
const button = document.querySelector(".my-button");
const element = document.querySelector(".content");
button.addEventListener("click", function() {
element.classList.toggle("sparkles");
});
We could use that skill to build some tabs, right? Right.
We got this.
Say we have this changing classes ability in our skillset now and we need to build a tabbed interface. If we just add a little more code that deals with click handlers, we could probably wire up some simple tabs, like this:
See the Pen
XQpqZV by Chris Coyier (@chriscoyier)
on CodePen.
Totally functional tabs. I might pat myself on the back a little here. See how I used those anchor links to create jump links between the link and the tabbed section? That’s mighty semantic, don’t you think? The tabs are accessible with a keyboard, have focus styles, and can be activated with the Return key.
Did we win? Case closed? Perfect tabs?
Nothing is ever so easy, is it?
One issue here is that we didn’t do anything special with keyboard handling, which tabbed interfaces may require. Heydon Pickering wrote about this:
Unlike a same-page link, a tab does not move the user to the associated section/panel of content. It just reveals the content visually. This is advantageous to sighted users (including sighted screen reader users) who wish to flit between different sections without having to wade back up the page each time they want to choose a new one.
This comes with an unfortunate side effect: If the user wishes to move to a section by keyboard and interact with its internal content, they have to step through any tabs to the right of the current tab, which are in focus order.
Turns out there is a whole checklist of other behavioral things tabs interfaces can and should be doing. In Heydon’s explanation, the Tab key actually acts as a way to jump from the tab itself to the content related to that tab, actually moving the focus. Shift+Tab brings them back. Then the arrow keys are used to change tabs. All this requires more JavaScript and even some HTML to allow for the focus state… plus a sprinkle of aria-*
attributes which I lack the expertise to explain you why they are important at all.
In the end, like this:
See the Pen
Tab Interface (PE) by Heydon (@heydon)
on CodePen.
So the question becomes: are our class-changing skills actually a detriment to the web because they don’t account for things like this? Is doing things with whatever basic tools we have a net loss for web accessibility? I dunno. Too big of a question for my little brain. It’s interesting to consider, though.
Part of it comes down to muscle memory.
If we learn to code tabs like that first demo there, we’ll tend to reach for that over and over so long as nobody bites our fingers off for doing it. I coded that demo in about three minutes because I’ve done it so many times. Creating those tabs is certainly part of my muscle memory.
There is plenty of talk about JavaScript frameworks being a scourge across the web because they seem to be ushering in an era of worst-in-class accessibility. But what if your muscle memory for building tabs was reaching for a pre-built tabs UI that brings along all the right functionality and left styling largely to you?
That’s what Reach UI tabs are (which assumes we’re working with React…).
I’m not telling you to go out and switch your projects to React so you can get some free tabs, but React is already massive. If good patterns like this become the defacto choice, then it’s possible that the effect is a net gain on accessibility. Seems possible to me, anyway. It might just stop me from poorly hand-coding a tabbed interface for the 359th time.
My litmus test when looking at tabs, is how does deal with overflow. 99% of the tab library / modules dont, so they end up dropping down to the next line.
I’ve found that with modern layouts, it’s not so complicated.
If you used a fieldset as your container, and layout your tabs as radio, label, content, you can use layout ordering and content stacking to create fully accesible tabs. Only javascript you need is to ensure that focused content in your tabs is visible
Grid example:
thank you for the useful post, there’s an important question however.
from SEO point of view, does using tabs hurt the indexing process. I mean will the whole content still be indexed when using tabs?
React and its “genius” idea of turning things into quasi-links .. oh yeah. Accessibility gone wrong .. BADLY.
Whenever I encounter a site which does not have ANY kind of link involved, but just some facny JS magic shite .. I leave. And if I’m in a rather foul mood, I drop a nasty flame down the throat whoever came up with it.
BTT: One can haz do fancy UX / AX tabs even without the magic of JS, no? :target is a big helper with this. And then, after that, we just add some JS sprinkle on top .. once upon a time there was even a fancy name for this magic trick (which I’ve apparently forgotten because all of the “responsiveness” and “appishness” going on in the 2010s ..).
Maybe RESPONSIBLE Javascript? would be a fancy new word :)
cu, w0lf.
Guess I’ve remembered the lovely word again: UNOBTRUSIVE Javascript :)
And how is this lovely piece of tab culture going to look like on mobile devices? Is it gonna turn into an accordeon? And how is THAT still decently accessible? …
cu, w0lf.