Tabs: It's Complicated™

When junior front-end developers learn JavaScript, mastering switching class names is a fast and effective technique.

 const button = document.querySelector(".my-button");
const element = document.querySelector(".content");

button.addEventListener("click", function() {
  element.classList.toggle("sparkles");
});

Using this trick, we can build tabs.

Simple implementation

If we have mastered the skills of switching class names, we need to build a tab interface. Just add some code to handle click events to implement simple tabs, such as:

These tabs are fully available. I use anchor links to create jump links between links and tab areas, which is semantically reasonable. The tabs are accessible via the keyboard, have a focus style, and can be activated using the Return key.

But is this enough? Perfect tab?

Not easy

The problem is that we don't do any special treatment for keyboard processing, and the tab interface may require keyboard processing. Heydon Pickering explains this:

Unlike links to the same page, the tab does not move the user to the associated content area/panel. It just displays content visually. This is beneficial for users who want to switch between different areas without returning to the top of the page every time (including those who use screen readers).

This brings an unfortunate side effect: If a user wants to move to an area through the keyboard and interact with their internal content, they must sequentially traverse all the tabs to the right of the current tab, which are arranged in focus.

It turns out that there are many other behavioral aspects to consider in the tab interface. In Heydon's explanation, the Tab key can actually be used as a way to jump from the tab itself to what is related to that tab, thus moving the focus. Shift Tab brings focus back. Then use the arrow keys to change the tab. All of this requires more JavaScript, and even some HTML to allow focus state...plus some aria-* attributes, I don't have enough expertise to explain why they are important.

The final result is as follows:

So the question becomes: Are our skills to switch class names harmful to the web because they don't take these aspects into account? Will using any basic tools compromise the accessibility of the web? I have no idea. This problem is too big for me. However, this is a question worth thinking about.

Muscle memory

If we first learn to write tabs like the first demo, as long as no one criticizes us for doing so, we will use it over and over again. I wrote the demo in about three minutes because I've done it many times. Creating these tabs is definitely part of my muscle memory.

Many people think JavaScript frameworks are a scourge on the web, because they seem to be leading an era of the worst accessibility. But what if the muscle memory of building a tab is to use a pre-built tab UI, it brings all the right features and leaves the style mainly to you?

This is the Reach UI tab (assuming we use React...).

I'm not asking you to switch your project to React to get some free tabs, but React is already huge. If such a good mode becomes a de facto choice, the effect may be a net gain on accessibility. At least it's possible for me. It might prevent me from botchedly writing the tab interface manually for the 359th time.

The above is the detailed content of Tabs: It's Complicated™. For more information, please follow other related articles on the PHP Chinese website!