Accessible, Global, Printable

Tailwind gives you variants for the user's preferences and situation: focus-visible:, motion-reduce:, contrast-more:, forced-colors:, rtl:, print:. The variants are easy to write and easy to get wrong without noticing, because a page that ignores these needs still looks fine to its author. So this chapter does what the earlier ones did: it turns each preference on in a real browser and measures what happens. The course Web Accessibility (a11y) covers the standards and the reasoning in depth; this chapter is about the Tailwind side.

Focus Styles

Keyboard users need to see where they are. Three habits matter, and I tested each on four controls: a button using focus:, a button using focus-visible:, a button with outline-hidden and no replacement, and a text input using focus-visible:. I clicked each with the mouse, then pressed Tab from a fresh page load.

The pattern to adopt: use focus-visible: for the ring (mouse users on buttons are not shown it, keyboard users always are), and never use outline-hidden or outline-none without putting a visible replacement on focus-visible:. The third button is the classic bug: it looks tidier and has no focus indicator at all. Chapter 8 explained that outline-hidden keeps a transparent outline in forced-colours mode; it still shows nothing in normal mode.

Text for Screen Readers Only

A star icon on a link has no text. You can add text that is invisible on screen but still read aloud. But hidden and invisible remove text from assistive technology as well. I asked Chrome for the accessibility tree and read the name it computed for each of five links:

Only sr-only keeps the words in the name. The same trick builds a skip link, a link that is invisible until a keyboard user reaches it:

focus:not-sr-only undoes the hiding exactly when the link receives focus, which is why the skip link is both hidden for mouse users and reachable by keyboard.

Contrast

The WCAG minimum for normal text is 4.5 to 1 (3 to 1 for large text and interface parts). Tailwind's palette is not guaranteed to meet it, and the common mistakes are light greys and white text on mid-tone colours. I measured the ratio for common pairs by reading each element's computed colours, converting them to sRGB through a canvas, and applying the WCAG formula:

Two surprises. A grey that passes on white (slate-500, 4.76) fails on a light grey panel (4.35). And white on emerald-500 is only 2.47, worse than most people guess; one step darker passes. Users can also ask for more or less contrast, and Tailwind has variants for that. With contrast-more: and contrast-less: set on a paragraph and a border, I switched Chrome's emulated prefers-contrast:

Reduced Motion

Some people feel ill from animation. The setting is prefers-reduced-motion; Tailwind gives two variants, motion-reduce: (the user asked for less) and motion-safe: (they did not). I used four elements and switched the emulated preference:

The lesson is in the first row: nothing is automatic. An animation without one of the two variants runs for everybody. The safer default is motion-safe: on the animation itself, so that it exists only when the user has not asked for less.

Forced Colours

In Windows High Contrast and similar modes the browser replaces your colours with the user's chosen system palette. The variant is forced-colors:, with not-forced-colors: for the opposite and forced-color-adjust-none to opt an element out. I switched Chrome's emulated forced-colors: active:

The browser already handled x2, so you rarely need to write forced-colors: yourself. The value of forced-color-adjust-none is also its danger: x3 kept your colours, so you now own the contrast. The cases that need a variant are decorative separators and custom controls built from background colours alone: in forced colours a background-only bar can vanish, so give it a border or an outline. I tested with Chrome's emulation, not a real Windows contrast theme.

Logical Properties and Right-to-Left

ml-4 always means "left". For a right-to-left language (Arabic, Hebrew) you want "start". Tailwind's logical utilities (ms-, me-, ps-, pe-, border-s, start-, end-, text-start) follow the writing direction. I laid out one block with logical classes and one with physical ones, then set dir="rtl" on their container:

The logical block mirrored by itself; the physical one stayed put. rtl: and ltr: are for the cases logical utilities cannot express (an icon that must flip, or a different colour). Tailwind 4.3.3 also has logical block-axis utilities. I built each and checked the generated declaration:

Note the last row: the CSS property names (padding-inline-start) suggest pis-, but Tailwind's inline-axis names are the shorter ps- and pe-, and the block-axis ones are pbs- and pbe-. I did not check which Tailwind release added the block-axis utilities; they exist in 4.3.3.

Print Styles

The print: variant applies under @media print. I emulated print media for the computed styles, and used Chrome's PDF output (A4, 0.4 inch margins) to see real page breaks:

The PDF test used a navigation bar (160 px tall) and three sections of 320 px:

Hiding the navigation brought the document from two pages to one; break-before-page forces a section onto its own page. break-inside-avoid is the companion that keeps a card from splitting across two pages. One thing I assumed and got wrong: Tailwind 4.3.3 has no print-color-adjust utility (print-color-adjust-exact produced no rule). The arbitrary property [print-color-adjust:exact] does work, and does generate print-color-adjust: exact. Whether backgrounds print also depends on the user's print dialog; my PDF test asked for them explicitly (printBackground). The site's own PDF builder works by loading chapters in headless Chrome, so print: rules in a chapter should apply to its PDF (I did not test that builder).

An Accessibility Review Checklist for Tailwind

• Every interactive element has a visible keyboard focus style on focus-visible:; no bare outline-hidden or outline-none.
• Icon-only controls have a name: sr-only text or aria-label; never hidden or invisible text.
• A skip link exists (sr-only focus:not-sr-only).
• Text and interface colours pass the WCAG ratios (measure; do not guess: emerald-500 with white text fails); contrast-more: variants for subtle greys.
• Every animation is under motion-safe: or has motion-reduce: alternatives.
• No meaning conveyed by background colour alone (forced colours removes it); forced-color-adjust-none only where you have checked contrast.
• Layout uses logical utilities (ms-, ps-, start-, text-start); rtl: only for things that must flip.
• Print: hide navigation, show URLs or notes if needed, set break behaviour, and test the PDF.

Hands-On Exercises