28 Tailwind CSS Close Buttons

Demo 01 uses absolute top-3 end-3 on the button, so it anchors to the corner of the nearest positioned ancestor — which means the dialog card itself needs relative, or the X escapes to the page corner. That is the most common bug with this pattern. Use the logical end-3 rather than right-3 so the control mirrors correctly in right-to-left layouts. The glyph is a real icon button, not text, so it carries an aria-label like "Close dialog" and a type="button" attribute to stop it submitting a surrounding form. The 44px circle is a deliberate target size — the visible ring is smaller, but padding inflates the hit area so a thumb never misses. Keep the X above the card's own content in the stacking order with a small z-index if the card scrolls its body.

An icon-only button has no accessible name, so every demo here gives it aria-label="Close" and the actual glyph is marked decorative. Demo 02 adds the keyboard half: focus-visible:outline-3 paints a visible ring only when the button is reached by Tab, not on mouse click, so pointer users never see a stray outline while keyboard users always do. Never suppress the ring with outline-none and no replacement — that fails WCAG 2.4.7. The ring uses an offset so it stays visible on both light and dark surfaces. Demo 10 goes further by building the panel on a native <dialog> element: the browser traps focus inside, Esc closes it for free, and focus returns to the trigger on close. If you hand-roll a <div> overlay instead, you inherit all of that focus management yourself.

Demo 13 wraps the glyph in a parent marked group and spins the inner X with group-hover:rotate-180 plus a transition and a duration. Rotating the parent would also move the focus ring and any label, so only the inner span turns — that separation is the whole trick. Add group-focus-visible:rotate-180 alongside the hover variant so keyboard users get the same feedback; hover-only animation is invisible to anyone not using a pointer. The rotation is purely cosmetic, so it belongs behind a motion-reduce:transition-none or a @media (prefers-reduced-motion: reduce) guard — a spinning X on every hover is exactly the kind of small motion that triggers vestibular discomfort. Because it is a transform, it runs on the compositor and never reflows the button, so it is cheap even on a list of many close buttons.

A close X that is visually 16 or 20px is a real accessibility failure on touch — fingers miss it and users rage-tap the content behind it. Demo 06 fixes this the correct way: the visible dot stays a 20px mark, but p-3.5 inflates the total interactive box to a 48×48 tap target, matching the platform minimum. The padding is transparent, so the design still reads as a small dot while the hit area is large. Do not chase the size by scaling the icon up — a giant X looks clumsy and still fails if the surrounding padding is zero. If two dismiss controls sit close together, give each its own 48px box and add a little gap so their targets do not overlap. On banners and ads this is not optional; a mistargeted close is the difference between a dismiss and an accidental click-through.

Demo 08 stacks three bars and transforms them on a toggled state. The top bar drops with translate-y-2.5 and rotates rotate-45, the bottom bar rises the same distance and rotates the opposite way, and the middle bar fades to opacity-0 so the two crossing bars read as an X. The bug people hit is the pivot: unless the bars share a transform origin at their common center, the rotation swings them apart instead of crossing. Set the origin to center and match the translate distance to the bar gap so the ends meet cleanly. This control is a toggle, not a plain close, so it needs aria-expanded reflecting the open state and an aria-controls pointing at the menu it operates — a screen reader has to announce "expanded" or "collapsed," which the visual morph alone never conveys. Guard the transition with motion-reduce.

Demo 24 adds friction to a dangerous dismiss so a stray tap cannot wipe something. A conic-gradient progress ring fills while the pointer is held down and only completes after 900ms; release early and it resets. The mechanism is a CSS animation on the ring bound to the button's active/pressed state, with a script confirming the action only once the fill reaches full. The critical detail is that pointerdown starting the fill must be paired with both pointerup and pointercancel to reset — miss pointercancel and a scroll gesture that steals the pointer leaves the ring stuck mid-fill. For keyboard parity, treat a held Enter or a two-step confirm as the equivalent, because you cannot "press and hold" with a keyboard. Reserve this for genuinely destructive closes; on an ordinary modal it just makes people hold a button for no reason.

Most are pure CSS. Hover, rotate, fold, neon, glitch, spring, ribbon and the galaxy vortex are all driven by transition, @keyframes, :hover and @property — no script runs. The ones that genuinely need JavaScript are the ones reacting to a runtime measurement or a real event. Demo 18's Material ripple records the exact press point into custom properties --tcb18-rx and --tcb18-ry so the ink expands from where you clicked; CSS alone cannot read a click coordinate. Demo 14's magnetic button reads the cursor position inside its field to lean the X toward it. Demo 24's hold-to-confirm needs a timer to fire the action, and Demo 10's native <dialog> uses showModal(). For the CSS-only ones, closing the panel is still your job — the button styles the control, but you wire the actual dismiss to state or to <dialog>.

The showcase demos — liquid goo, glitch, galaxy vortex, neon strike, particle burst, trash compactor — are fun but they draw the eye and cost attention, so keep them off high-frequency, task-critical dismissals. A cookie banner, an error toast or a payment modal wants the quiet corner X from Demo 01 or the WCAG-clean button from Demo 02, where the goal is "get out of my way instantly." An animation that delays the visible dismiss by a few hundred milliseconds reads as lag. Anything with continuous motion — the vortex, the neon idle glow — must respect prefers-reduced-motion or it becomes an accessibility problem, and a perpetually animating element also keeps the compositor busy. Reserve the elaborate ones for a single hero moment, such as closing a full-screen lightbox, and never put more than one on screen at a time — a grid of spinning, glitching close buttons reads as noise, not polish.