:focus-visible vs :focus Demo — Free HTML CSS JS Snippet

Focus styling is one of the most frequently botched pieces of accessible UI on the web. For years, developers had exactly one option — the :focus pseudo-class — which fires the moment ANY element receives keyboard input focus, including when a user simply clicks a button with a mouse. Because default browser focus rings (that blue glow around a clicked button) looked visually noisy to many designers, an enormous number of sites shipped *:focus { outline: none; } globally, silently stripping keyboard focus indication sitewide and making the page unusable for keyboard and switch-device users. :focus-visible, standardized in the CSS Selectors Level 4 spec and shipped natively in all major browsers since 2020-2021, fixes this by letting the browser itself decide, using its own heuristics, whether a focus event was likely triggered by keyboard/assistive-technology navigation (show a ring) versus a direct pointer interaction (usually suppress it).

The actual browser heuristic

:focus-visible is not simply "keyboard = true, mouse = false." The specification defines heuristics that browsers implement slightly differently but converge on in practice: a <button>, <a>, or a plain <div tabindex="0"> clicked directly with a mouse generally does NOT match :focus-visible (because the user can already see what they clicked, a ring adds little value), but that same click on a <button> still matches :focus. Meanwhile a text <input> clicked with a mouse DOES typically still match :focus-visible, because focusing a text field is itself an implicit signal you're about to type and the insertion point benefits from a clear visual anchor. Any focus reached via Tab, Shift+Tab, arrow-key navigation inside composite widgets, or a screen reader's virtual cursor reliably matches :focus-visible across every interactive element type. Programmatic focus via el.focus() in JavaScript inherits the visibility state of whatever interaction triggered it, with document-level heuristics as a fallback.

Why this distinction matters for real products

Before :focus-visible existed, teams had to choose between two bad options: leave the default mouse-triggered focus ring in place (which many stakeholders reject as "ugly," clicking any button leaves a visible blue box) or strip focus outlines entirely with outline: none (which is a WCAG 2.4.7 "Focus Visible" failure and breaks the product for keyboard-only and switch-device users, a legally significant accessibility gap under ADA/Section 508 in many jurisdictions). :focus-visible resolves the tension natively, with zero JavaScript: style :focus-visible with your polished, prominent focus ring, and optionally leave a lighter or absent :focus style for pointer interactions, letting the browser's own input-method detection do the work that used to require third-party libraries like the old focus-visible polyfill (a JS library shimming this exact behavior before native support existed).

What this playground demonstrates

Four different interactive elements — a <button>, a text <input>, an <a> link, and a plain <div tabindex="0"> — are each styled with two competing rules: .demo-el:focus applies a dashed blue outline unconditionally, and .demo-el:focus-visible applies a solid indigo ring with a soft glow that visually wins whenever it also matches (later rule, higher specificity of the more precise selector in practice, though both are single pseudo-classes here so declaration order decides). Click each element with your mouse, then Tab through them with your keyboard, and watch the live interaction log at the bottom record, in real time, whether :focus-visible matched for that exact focus event — captured by calling element.matches(':focus-visible') inside a focusin listener. You'll observe the button, link, and custom div suppress the indigo ring on a raw mouse click while the text input keeps it, exactly matching the spec's documented heuristic, and every Tab-driven focus event shows the ring regardless of element type.

Implementation notes for your own components

Because :focus-visible needs no JavaScript feature detection or event listener to use in production CSS — the interaction log here is purely a teaching aid, not a requirement — you can adopt it today by simply replacing outline: none reset rules with a deliberate :focus-visible ring and, if you want a subtler acknowledgment for pointer users, a lighter :focus:not(:focus-visible) style. Support has existed in Chrome/Edge since 86, Firefox since 85, and Safari since 15.4, so no polyfill is needed in 2025/2026 codebases.