Building a Simple Tabs Component Where JavaScript Serves the CSS
Build a tabs component where JavaScript only toggles data-state attributes and ARIA, leaving the visual logic to CSS cascade, scroll-driven animations, and container queries.
Your tabs component does not need a framework, a state manager, or an IntersectionObserver. The minimum JavaScript is one line inside a click handler: toggle a data-state value on the tablist, then mirror that state to the aria-selected attributes on the tabs and the hidden state of the panels. Everything that makes the tabs look active, fade, slide, or scroll into view is CSS. The JavaScript serves the CSS, not the other way around. Here are three complete, runnable samples, each with its own failure case, and the older technique each one replaces. Start with the CSS-only approach, because it taught the browsers what tabs need, then move to the scroll-driven animation, then to the production component you would actually ship.
CSS-Only Tabs With :target
The `:target` pseudo-class is the oldest trick that works without a single line of script. Put an `id` on each tab panel, make each tab an anchor pointing at that `id`, and use `:target` to show the panel whose `id` matches the URL fragment. The non-matching panels stay hidden with `display: none`. The technique works. It is still the right answer for a page where tabs are a progressive enhancement. It has two hard limitations you need to name before you build on it.
Here is the full sample:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>CSS-only tabs with :target</title>
<style>
.tabs { display: flex; gap: 0.5rem; }
.tab-panel {
display: none;
padding: 1rem;
border: 1px solid #ccc;
}
.tab-panel:target {
display: block;
}
/* Default visible panel: the first one when no fragment matches */
.tab-panel:not(:target) ~ .tab-panel:first-of-type {
display: block;
}
</style>
</head>
<body>
<div class="tabs" role="tablist" aria-label="Sample tabs">
<a href="#tab1" role="tab" aria-selected="true">Alpha</a>
<a href="#tab2" role="tab" aria-selected="false">Beta</a>
<a href="#tab3" role="tab" aria-selected="false">Gamma</a>
</div>
<div id="tab1" class="tab-panel" role="tabpanel" aria-labelledby="tab1">First panel content.</div>
<div id="tab2" class="tab-panel" role="tabpanel" aria-labelledby="tab2">Second panel content.</div>
<div id="tab3" class="tab-panel" role="tabpanel" aria-labelledby="tab3">Third panel content.</div>
</body>
</html>
The first limitation is focus. Arrow-key navigation between tabs requires JavaScript, because the browser does not move focus between anchors on its own. The second is history. Every tab activation pushes a new entry into the browser history, so the back button walks through every tab you opened. That is annoying on a long page and it is a real accessibility problem for users who navigate with the keyboard and the back button both.
The `:target` approach replaces the JavaScript-driven tab switching that used `onclick` event handlers and class toggling. Use it when you can live with the history pollution and you do not need arrow keys. If you need those, the approach below keeps the CSS-only feel but adds the minimal script that the accessibility tree demands.
Scroll-Driven Tabs With The view() Timeline
The `view()` timeline is the modern replacement for IntersectionObserver. Instead of watching which panel is in the viewport and toggling a class from JavaScript, you declare an animation that progresses as the panel scrolls through the scrollport. The animation sets the active tab's background, and the browser runs it on the compositor thread. It never touches the main thread and it never janks.
Here is the full sample:
/* Scroll-driven tabs: the panel's progress through the viewport drives the tab highlight */
@supports (animation-timeline: view()) {
.tab-strip {
display: flex;
gap: 0.5rem;
position: sticky;
top: 0;
background: #fff;
z-index: 1;
}
.tab-strip a {
padding: 0.5rem 1rem;
text-decoration: none;
color: #333;
border-bottom: 3px solid transparent;
}
.tab-panel-scroll {
height: 60vh;
overflow-y: auto;
}
.panel {
min-height: 100%;
padding: 1rem;
border-bottom: 1px solid #eee;
}
.tab-strip a {
animation: tab-highlight linear both;
animation-timeline: view();
animation-range: entry 0% exit 100%;
}
@keyframes tab-highlight {
0%, 49% { border-bottom-color: transparent; }
50%, 100% { border-bottom-color: #06c; }
}
}
<div class="tab-strip" role="tablist" aria-label="Scroll tabs">
<a href="#scroll-panel-1" role="tab" aria-selected="true">One</a>
<a href="#scroll-panel-2" role="tab" aria-selected="false">Two</a>
<a href="#scroll-panel-3" role="tab" aria-selected="false">Three</a>
</div>
<div class="tab-panel-scroll">
<section id="scroll-panel-1" class="panel" role="tabpanel" aria-labelledby="scroll-panel-1">First panel.</section>
<section id="scroll-panel-2" class="panel" role="tabpanel" aria-labelledby="scroll-panel-2">Second panel.</section>
<section id="scroll-panel-3" class="panel" role="tabpanel" aria-labelledby="scroll-panel-3">Third panel.</section>
</div>
This technique replaces the all-JavaScript scroll spy, the kind that added an active class to a nav link every time the scroll position crossed a threshold. That old approach ran on the main thread, needed a `requestAnimationFrame` loop or a throttled scroll listener, and could miss the active state entirely when the user scrolled fast. The `view()` timeline hands the same job to the browser's compositor, which does it once per frame and never blocks the main thread.
The failure case is support. The `@supports (animation-timeline: view())` guard is mandatory, and when it fails you need a fallback. The fallback is the same component with the `data-state` approach below, or a simple IntersectionObserver if you must keep the scroll behaviour. Never ship scroll-driven tabs without the `@supports` guard. An unsupported `animation-timeline` value silently does nothing, and your tabs will look like a flat list of links with no active state at all.
Production-Ready Tabs Component
The `data-state` value is the contract between JavaScript and CSS. The JavaScript toggles the value on the tablist, and the CSS reads that value to style the active tab and hide the inactive panels. It is not a class, so it cannot collide with a framework's class names. It carries state in a way that is inspectable in the devtools and testable in a unit test.
Here is the full sample:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Data-state tabs</title>
<style>
.tabs-prod {
display: flex;
gap: 0.5rem;
}
.tab-prod {
padding: 0.5rem 1rem;
border: 1px solid #ccc;
background: #f5f5f5;
cursor: pointer;
}
.tab-panel-prod {
display: none;
padding: 1rem;
border: 1px solid #ccc;
}
.tabs-prod[data-state="tab-1"] .tab-panel-prod[data-panel="1"],
.tabs-prod[data-state="tab-2"] .tab-panel-prod[data-panel="2"],
.tabs-prod[data-state="tab-3"] .tab-panel-prod[data-panel="3"] {
display: block;
}
.tabs-prod[data-state="tab-1"] .tab-prod[data-tab="1"],
.tabs-prod[data-state="tab-2"] .tab-prod[data-tab="2"],
.tabs-prod[data-state="tab-3"] .tab-prod[data-tab="3"] {
background: #06c;
color: #fff;
border-color: #06c;
}
@media (forced-colors: active) {
.tab-prod[aria-selected="true"] {
outline: 2px solid Highlight;
}
}
@media (prefers-reduced-motion: reduce) {
.tab-panel-prod {
transition: none;
}
}
</style>
</head>
<body>
<div class="tabs-prod" role="tablist" aria-label="Production tabs" data-state="tab-1">
<button class="tab-prod" role="tab" aria-selected="true" aria-controls="prod-panel-1" data-tab="1">One</button>
<button class="tab-prod" role="tab" aria-selected="false" aria-controls="prod-panel-2" data-tab="2">Two</button>
<button class="tab-prod" role="tab" aria-selected="false" aria-controls="prod-panel-3" data-tab="3">Three</button>
</div>
<div class="tab-panel-prod" id="prod-panel-1" role="tabpanel" aria-labelledby="prod-tab-1" data-panel="1">First panel.</div>
<div class="tab-panel-prod" id="prod-panel-2" role="tabpanel" aria-labelledby="prod-tab-2" data-panel="2">Second panel.</div>
<div class="tab-panel-prod" id="prod-panel-3" role="tabpanel" aria-labelledby="prod-tab-3" data-panel="3">Third panel.</div>
<script>
const tablist = document.querySelector('.tabs-prod');
const tabs = tablist.querySelectorAll('.tab-prod');
const panels = document.querySelectorAll('.tab-panel-prod');
tabs.forEach((tab, index) => {
tab.addEventListener('click', () => {
tablist.dataset.state = 'tab-' + (index + 1);
tabs.forEach(t => t.setAttribute('aria-selected', t === tab ? 'true' : 'false'));
panels.forEach(p => {
p.hidden = p.id !== 'prod-panel-' + (index + 1);
});
});
});
</script>
</body>
</html>
That script is the absolute minimum. It updates the `data-state` value, which the CSS reads to style the active tab and show the right panel. It sets `aria-selected` to tell the accessibility tree which tab is active, and it toggles the `hidden` property on the panels, which removes them from the accessibility tree so screen readers do not announce inactive panels. The CSS never needs to know which panel is active except through the `data-state` value, and the JavaScript never needs to know a single style rule.
This component replaces the jQuery UI tabs widget, which carried a plugin's worth of JavaScript, a theme stylesheet, and a dozen classes for states like `ui-state-active` and `ui-state-hover`. It also replaces the React state-managed tab, where every click dispatches an action, runs a reducer, and re-renders the virtual DOM. Here the state lives in the DOM, the CSS reads it directly, and there is no component tree to reconcile.
The failure case is focus management. The click handler toggles state, but it does not move focus. In the WAI-ARIA tabs pattern, arrow keys move focus between tabs, and the active tab takes focus when the tablist receives it. That requires a `keydown` listener, and it is the one piece of JavaScript this component cannot avoid. If you skip it, keyboard users can still click each tab, but they cannot navigate with the arrow keys, and that is a WCAG failure under 2.1.1 Keyboard. Add the `keydown` handler, and the component is complete.
Progressive Enhancement Tabs
The `data-state` approach is the base layer, and the `:target` approach is the no-JavaScript fallback. Serve the `:target` version to browsers without script support. When JavaScript loads, add the `data-state` value and the `keydown` handler. The `@supports selector()` guard for `:target` keeps the fallback from leaking into browsers that do not support it.
Here is the full sample:
/* Base: the :target pattern as a no-JS fallback */
.tab-panel-enh {
display: none;
}
.tab-panel-enh:target {
display: block;
}
.tab-panel-enh:not(:target) ~ .tab-panel-enh:first-of-type {
display: block;
}
/* Enhancement: data-state takes over when JavaScript runs */
.js-enabled .tabs-enh {
display: flex;
}
.js-enabled .tab-panel-enh {
display: none;
}
.js-enabled .tabs-enh[data-state="tab-1"] .tab-panel-enh[data-panel="1"],
.js-enabled .tabs-enh[data-state="tab-2"] .tab-panel-enh[data-panel="2"],
.js-enabled .tabs-enh[data-state="tab-3"] .tab-panel-enh[data-panel="3"] {
display: block;
}
<div class="tabs-enh" role="tablist" aria-label="Enhanced tabs" data-state="tab-1">
<a href="#enh-panel-1" class="tab-enh" role="tab" aria-selected="true" data-tab="1">One</a>
<a href="#enh-panel-2" class="tab-enh" role="tab" aria-selected="false" data-tab="2">Two</a>
<a href="#enh-panel-3" class="tab-enh" role="tab" aria-selected="false" data-tab="3">Three</a>
</div>
<div id="enh-panel-1" class="tab-panel-enh" role="tabpanel" aria-labelledby="enh-tab-1" data-panel="1">First panel.</div>
<div id="enh-panel-2" class="tab-panel-enh" role="tabpanel" aria-labelledby="enh-tab-2" data-panel="2">Second panel.</div>
<div id="enh-panel-3" class="tab-panel-enh" role="tabpanel" aria-labelledby="enh-tab-3" data-panel="3">Third panel.</div>
<script>
document.documentElement.classList.add('js-enabled');
const tablistEnh = document.querySelector('.tabs-enh');
const tabsEnh = tablistEnh.querySelectorAll('.tab-enh');
const panelsEnh = document.querySelectorAll('.tab-panel-enh');
tabsEnh.forEach((tab, index) => {
tab.addEventListener('click', (e) => {
e.preventDefault();
tablistEnh.dataset.state = 'tab-' + (index + 1);
tabsEnh.forEach(t => t.setAttribute('aria-selected', t === tab ? 'true' : 'false'));
panelsEnh.forEach(p => {
p.hidden = p.id !== 'enh-panel-' + (index + 1);
});
});
});
</script>
This approach replaces the all-JavaScript tab system that leaves no content visible when the script fails or is blocked. The fallback is not a blank page; it is the `:target` version, which works in every browser that supports fragment navigation. The enhancement layer adds the `data-state` value, the ARIA updates, and the focus management, so the component is accessible and functional in the modern browser while remaining usable in the oldest one.
The failure case is the moment the script loads but the `@supports selector()` check fails. In that case, the `:target` rules apply, the `.js-enabled` rules do not exist, and the component works as a pure anchor navigation. That is not a bug; it is the progressive enhancement doing its job. The script adds the class before the click handler is attached, so there is no flash of unstyled content between the `:target` rules and the `data-state` rules.
Limitations Of The :target Approach
The `:target` approach has a specific set of failure modes. The first is the history accumulation, which we covered. The second is the default panel logic. The selector `.tab-panel:not(:target) ~ .tab-panel:first-of-type` is fragile because it depends on the first panel being the one that shows when no fragment matches. If the URL has a fragment for a different panel, the first panel hides and the targeted one shows, which is correct. But if the fragment is for a non-existent `id`, every panel hides and the page is blank, which is a failure.
Another failure is the cascade layer interaction. If you put the `:target` rules inside a `@layer`, the unlayered author styles will override them regardless of specificity, because unlayered styles beat layered styles. That is a common mistake when adding a tab technique to an existing design system that already uses `@layer`. The fix is to put the tab styles in the same layer as the rest of the component, or to leave them unlayered.
The third failure is the `animation-fill-mode` interaction. If you animate the tab panels with a CSS transition, the `:target` rule changing `display` from `none` to `block` does not transition, because `display` is not an animatable property. The panel appears instantly, and the transition on `opacity` or `transform` does not run. To get a fade, animate the `opacity` and the `transform`, not the `display`, and keep the panel in the layout with a `hidden` property or a `visibility` toggle, not `display: none`. The `data-state` approach avoids this because the CSS can apply a transition on the `opacity` of the active panel without changing its `display`.
The fourth failure is the `@supports selector()` guard. The `:target` pseudo-class is supported in every browser that has ever shipped it, so the guard is almost always true. But the guard is still useful when you layer `:target` with `popover`, because the `popover` property has a different support timeline. Use `@supports (selector([popover]:open))` to guard the popover-based tabs, not the `:target`-based ones.
Limitations Of The Scroll-Driven Approach
The `view()` timeline is not a drop-in replacement for every scroll spy. The `animation-range` property controls when the animation starts and stops, and getting it wrong produces a tab that highlights too early or too late. The range `entry 0% exit 100%` means the animation starts when the panel enters the scrollport and ends when it exits, which is the correct behaviour for a sticky tab strip. But if you use a vertical scroll container with a horizontal tab strip, the `view()` timeline tracks the vertical progress, not the horizontal, so the animation does not match the scroll direction.
The second limitation is the compositor thread. The animation runs on the compositor only if the animated properties are `transform` and `opacity`. If you animate `border-bottom-color`, as in the sample above, the browser may promote the animation to the main thread, and the performance benefit disappears. The safe choice is to animate `transform` and `opacity` only, and to change the color with a keyframe that flips at the midpoint, which the sample does. The `border-bottom-color` is not compositor-safe, so for a production scroll-driven tab, animate a pseudo-element's `transform` instead.
The third limitation is the fallback. The `@supports` guard is mandatory, but the fallback is not automatic. Write the fallback rules inside the `@supports` block or outside it, and test both paths. The `data-state` component is the reliable fallback, because it does not depend on scroll position at all. The user scrolls, and the JavaScript updates the state, which the CSS reads. That is the same behaviour the scroll-driven animation provides, but without the compositor benefit.
How The data-state Hook Works
The `data-state` value is a custom data attribute, not a state pseudo-class like `:checked` or `:target`. It is a plain string on the element, and the CSS attribute selector reads it. The name is arbitrary, but `data-state` is a convention that survives across design systems. The value is the active tab's identifier, and the CSS uses that value to select the panel and the tab.
The approach is declarative: the CSS declares the entire visual state space, one rule per possible `data-state` value. Three tabs means three rules. Ten tabs means ten rules, and that is the limitation. The CSS does not loop, so the number of rules grows linearly with the number of tabs. For a component with a fixed, small number of tabs, this is concise and readable. For a dynamic list, use a class toggle on the active tab and a sibling selector on the panel. The CSS can then use a single rule like `.tab-panel.active { display: block; }`.
The `data-state` hook also works with the accessibility tree in a way that classes do not. The `aria-selected` property is set by JavaScript, and the CSS does not read it. The CSS reads the `data-state` value, and the JavaScript sets both. That separation means the CSS can change without touching the JavaScript, and the JavaScript can change without touching the CSS. The `classList.toggle` method is the JavaScript API that most developers reach for, but for a `data-state` hook you use the `dataset` property, which is a direct mapping from `data-*` attributes to camelCase properties. The `dataset.state` setter writes `data-state`, and the CSS selector `[data-state="tab-1"]` reads it.
This technique replaces the class-toggle pattern where the class name carries both the visual state and the accessibility state. With a class, you might write `.tab.active { … }` and rely on the same class for `aria-selected`, which is a coupling. The `data-state` hook decouples them, so the accessibility tree is not dependent on the CSS class naming.
FAQ
Can CSS-only tabs be keyboard accessible without JavaScript?
No. The `:target` technique responds to clicks and to the browser's back button, but it does not move focus between tabs with arrow keys. The WAI-ARIA tabs pattern requires arrow-key navigation, and that requires a `keydown` event listener. The CSS-only approach is functional without JavaScript for mouse users and for screen reader users who activate links, but it fails the keyboard navigation requirement under WCAG 2.1.1.
When should I use the scroll-driven tabs animation instead of the data-state component?
Use the scroll-driven animation when the tabs are the primary navigation and the panels are long sections that the user scrolls through naturally. The animation provides a visual highlight without any JavaScript, and it runs on the compositor thread. Use the `data-state` component when the tabs are a compact widget below a form or in a modal, where the user clicks and expects immediate panel switching without scrolling.
What is the fallback when the data-state script fails to load?
The progressive enhancement pattern is the fallback. The `:target` rules work without JavaScript, so the panels are still reachable via anchors. The `data-state` rules only apply when the `.js-enabled` class is present, and the script adds that class before attaching the click handlers. If the script fails, the class is not added, the `:target` rules apply, and the component degrades to the anchor pattern.
Does the data-state value affect the accessibility tree directly?
No. The `data-state` value is not read by screen readers. The accessibility tree is affected by the `role`, `aria-selected`, and `hidden` attributes. The JavaScript sets `aria-selected` on the tabs and toggles `hidden` on the panels. The `data-state` value is only a CSS hook. If you forget to set `aria-selected`, the component looks correct visually but announces every tab as selected, which is a failure.
Can I animate the panel transition with the data-state component?
Yes, but not by animating `display`. The `display` property is not animatable, so the panel appears instantly. To get a fade, keep the panel in the layout with the `hidden` property and animate `opacity` and `transform`. The `hidden` property is not the same as `display: none` for CSS purposes: you can set `.tab-panel[hidden] { display: none; }` to remove it from the layout, but you cannot transition to that state. Instead, use the `hidden` property on the inactive panels and animate the active panel's `opacity` and `transform`.
Fixing The Border-Bottom-Color Jank
The scroll-driven tabs animation sample animates `border-bottom-color`, which is not compositor-safe. The practical fix is to animate a pseudo-element's `transform` instead. The compositor thread only handles `transform` and `opacity`, and the `border-bottom-color` animation will silently move to the main thread and jank on long pages.
