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.
The post Tabs: It’s Complicated™ appeared first on CSS-Tricks.
CSS-Tricks