21 Tailwind CSS Pricing Sections

Demo 04 runs the switch entirely in HTML and CSS. Two hidden radio <input> elements share one name; the visible pill is a pair of <label> elements, and the sliding gradient thumb is an absolutely-positioned element the checked radio drives through a sibling selector. Every price is two <span> stacked in the same grid cell — the yearly figure hidden by default. When the yearly radio is :checked, a :has() rule on the section (Tailwind's group-has-[…]:) flips which span shows and moves the thumb. Because the state lives in the radio rather than a script, it works before any hydration and survives a copy-paste into any stack. The one rule that matters: hide the radios with a visually-hidden clip, not display:none, or they drop out of the tab order and keyboard users can no longer flip billing.

Same radio-plus-:has() mechanism, scaled up. Demo 17 holds three currency radios and renders nine price spans; each visible price is a small stack where only the span matching the checked currency is shown, and a group-has-[…]: rule on the container decides which one. Demo 16 uses the pattern for preset amounts — five chip <label> elements over hidden radios, the checked chip lifting into a mint gradient, and the CTA label reacting to the selection through the same has-selector. The trap people hit is putting the state on the clicked element itself: keep the checked radio as the single source of truth and let ancestor :has() rules read it, so one interaction updates the price, the chip, and the button label in one repaint. All prices stay in the DOM, so nothing flashes in on load.

Demo 02 lifts the middle tier with scale and a taller card, and the usual bug is that the transform makes it visually larger while its grid track stays the same width, so the scaled edges bleed over the neighbouring cards. Fix it by giving the popular card real dimensions instead of only a transform — let it own a slightly wider or taller grid cell, add vertical padding, and use z-index so it sits above rather than under the siblings. If you keep the scale, add matching horizontal margin so the enlarged footprint has somewhere to go. The second cause is unequal card heights: put the tier row in a grid or flex container with align-items:stretch so every card matches the tallest, otherwise the lifted card looks like a layout accident rather than a deliberate emphasis. The 'Most popular' pill should be a real badge, not a pseudo-element, so screen readers announce it.

Demo 03 is a real <table>, which is exactly right — a comparison grid built from <div> elements gives assistive tech no row/column relationship to announce. The load-bearing detail is scope on both axes: the plan names across the top are <th scope="col"> and the feature names down the left edge are <th scope="row">. With both in place, a screen reader reading a checkmark cell announces the feature and the plan it belongs to, so a blind user knows Priority support — Business instead of a bare 'yes'. Give the table a <caption> naming what it compares. Avoid conveying included/excluded by colour alone — a green tick and a grey dash read identically to a colour-blind user, so pair each with a visible glyph or text. On narrow screens let the table scroll inside a wrapper with overflow-x:auto rather than collapsing columns, which usually destroys the header association.

Yes, these two are the interactive exceptions. Demo 05 is a range <input> whose value drives the estimate, the request count and the recommended tier; because a native range control is already keyboard-operable with arrow keys, the work is in the ARIA — set aria-valuenow, aria-valuemin, aria-valuemax and an aria-label so a screen reader reports the current usage, and wire the live figures through an element with aria-live so updates are spoken. Demo 11 drives per-seat math from native <button> plus/minus controls around a number <input>; keep it a real number field so typing, spinners and mobile numeric keyboards all work, give each button an aria-label like 'add a seat', and clamp the value in the handler so it can't go below one. In both, the script only reads a value and writes text — it never becomes the source of truth for the price the user copies.

Demo 12 registers a custom property with @property — typed as an <angle> with an initial value — then animates that angle from 0 to 360 degrees and feeds it into a conic-gradient painted behind the card. Registering the property is what makes the angle actually interpolate; a plain custom variable animated the same way jumps rather than spins, which is the number-one reason people's border 'doesn't move'. The gradient lives on a pseudo-element or a slightly larger backing layer with the card content masked on top, so only the rim shows colour. For browsers without @property support the animation simply won't run — so make the static gradient border look finished on its own, and always wrap the spin in @media (prefers-reduced-motion: reduce) to stop it, since a perpetually rotating rim is exactly the kind of motion that triggers discomfort.

Demo 20 tracks the pointer and moves an amber radial glow to follow it across the black cards, which by itself would be a mouse-only effect — a keyboard user tabbing through the plans would see nothing. The fix baked into this demo is that focusing a card with the keyboard lands the spotlight centred on it, so the same visual affordance that guides a mouse also marks the focused tier. Practically that means driving the glow position from two sources: pointer coordinates on mousemove, and a reset-to-centre on :focus-visible. Keep a real, visible focus ring underneath as well — the glow is decoration, not a focus indicator, and it must not be the only signal that a card is active. The whole effect is enhancement over a card that already reads correctly with no pointer and no script, so nothing about pricing or the CTA depends on the spotlight running.

Skip the Demo 03 comparison table when you have three or fewer plans with short feature lists — a nine-row grid there just adds scanning cost, and the three-card layouts (Demo 01, Demo 02) convert better because the eye compares whole tiers at a glance. Reach for the table only when plans differ across many features and buyers genuinely cross-shop line by line. Skip the Demo 04 billing toggle when you don't actually offer annual billing, or when the yearly discount is trivial — a toggle implies a meaningful saving, and an empty one erodes trust; the Demo 21 struck-through annual-savings stripe states the discount more honestly for a single plan. And don't ship the single premium card (Demo 06) when you have real tiers to show — one card hides the anchoring that makes a middle plan feel reasonable. Match the pattern to the number of plans and the size of the decision, not to which demo looks nicest.