Web development

focus-visible with Tailwind

Tailwind's focus-visible variant styles focus only when the browser expects it, usually from the keyboard. How to write it, test it and where it breaks.

Key points

  • focus-visible applies the style when the browser decides focus should be visible, usually from the keyboard.
  • Never use outline-none without a replacement: it removes the only focus signal.
  • The ring needs 3:1 contrast with the adjacent background, as WCAG 2.2 criterion 1.4.11 asks.

Tailwind's focus-visible variant styles focus only when the browser thinks showing it helps, in practice with the keyboard: a mouse click shows no ring, the Tab key does.

Where the difference lies

:focus matches every active element, even after a click. :focus-visible matches when the browser heuristic expects you to want a visible marker: keyboard, screen readers, focus moved by code after an action.


  Pricing

The example uses outline rather than ring because an outline takes no space in the layout and follows the border radius; outline-offset-2 lifts the ring off the button background.

Never outline-none on its own

Removing the outline without a replacement is the commonest defect: keyboard users lose the only signal. If the design asks for a different ring, replace rather than remove: focus-visible:outline-none focus-visible:ring-2 is acceptable, a global outline-none is not.

  • The ring needs a contrast ratio of at least 3:1 against the adjacent background: WCAG 2.2, success criterion 1.4.11, asks for it.
  • Focus stays visible on coloured backgrounds and in dark mode, not only on the light grey of the grid.
  • A custom control, such as a div with role="button", needs focus from Tab: without tabindex there is nothing to highlight.
  • Source: the tailwindcss.com documentation and W3C WCAG 2.2, read on 1 November 2026; MIT licence.

How to test it

Walk the page with Tab from start to finish and check three things: every step shows a ring, the order follows the content, and focus stays inside the open dialog. An automated test cannot see the ring: you need a human eye or a screenshot taken after the Tab.

Where it breaks

The heuristic is not a specification: Safari has changed behaviour several times and a .focus() call from JavaScript may not trigger :focus-visible. If the browser does not recognise the pseudo-class the rule is dropped and the element ends up with no ring, so a fallback with focus: is a decision, not an accident.

Where to continue

In the EneUI catalogue open login-01, login-form and onboarding-dialog, three forms where focus decides usability. The invisible ring case is in focus ring invisible; the full procedure in how to run an accessibility audit; the framework comparison in Tailwind against Bootstrap. The other two pieces in the series are animations without JavaScript and the spacing scale.

Frequently asked questions

What is the difference between focus and focus-visible?

focus matches every active element, even after a click. focus-visible matches when the browser decides focus should be shown, usually after the keyboard.

How do I write it in Tailwind?

Put the focus-visible variant in front of a utility, for example focus-visible:outline-2. The build emits a :focus-visible rule with the same property.

Can I remove the outline?

Only with a visible replacement, such as a ring or a border. outline-none with no alternative takes the indicator away from keyboard users.

What contrast does the ring need?

At least 3:1 against the adjacent colour, as WCAG 2.2 asks in criterion 1.4.11. Measure it against the real background, not the white of the grid.

Why does focus not appear on a div?

Because a div is not focusable by default. It needs tabindex="0" plus keyboard behaviour, or a native element such as button or a.