20 CSS Banners & Alerts

The visual banner is the easy part; the compliance is in the behaviour. Four requirements decide whether a consent banner does its job. Reject must be as easy as accept — a prominent "Accept all" beside a buried text link is exactly what regulators have fined companies over, so both actions need equal visual weight at the top level. No pre-ticked boxes: every non-essential category must default to off, since silence is not consent under GDPR Article 4(11). Granular categories are required, not optional — analytics, marketing and functional cookies each need their own toggle, which is why this collection's version ships a real preferences panel rather than a single accept button. And no scripts may fire before consent: the banner must gate the actual loading, so putting your analytics tag in the head and showing a banner underneath it is theatre. Technically the panel is a <dialog> or a disclosure with real <input type="checkbox"> controls, the choice persists in localStorage, and the whole thing carries role="dialog" with a labelled heading. Demo 01 is the reference. This is not legal advice — the pattern is sound, the specific categories are yours to determine.

It depends entirely on whether the message interrupts. Use role="alert" for something the user must know immediately — a failed payment, a validation error, a session about to expire. It implies aria-live="assertive", which interrupts whatever the screen reader is currently saying, and that is exactly why it should be rare. Use role="status" (implying aria-live="polite") for everything else: a saved confirmation, a promo bar, a shipping-progress update. Polite waits for a natural pause, which is the right default. Three details people miss. The live region must exist in the DOM before the message is injected — inserting the whole container at once often produces no announcement at all, so render an empty region and fill it. A purely decorative or promotional banner needs neither role; marking a sale bar as an alert is announcement spam. And a dismiss button must be a real <button> with an accessible name like "Dismiss announcement", not a bare × character, which screen readers read as "times".

Sticky and fixed banners cause more layout bugs than any other banner property, in three predictable ways. First, a position: fixed bar overlaps content because it is out of flow — the page needs compensating padding-block-start equal to the bar height, ideally driven by a custom property so one value updates both. position: sticky avoids this entirely by staying in flow, and is the better default for a top announcement bar. Second, stacking: a sticky bar must sit above page content but below modals and their backdrops, so give it a deliberate z-index from a documented scale rather than reaching for 9999. Third, sticky silently fails when any ancestor has overflow: hidden, auto or scroll — that ancestor becomes the scroll port and the bar stops sticking, which is why overflow-x: clip is the right way to kill horizontal scroll on a wrapper. On mobile, respect the safe area with padding-block-end: env(safe-area-inset-bottom) on bottom-anchored bars, or the home indicator will sit on your buttons.

This is the bug that breaks more banners than any other, and it is worth understanding rather than pasting a fix. A 96-character support URL, a German compound noun or a wallet address has no break opportunity, so the browser lets it overflow rather than break a word. Four properties, in escalating order. overflow-wrap: break-word breaks a long word only when it would otherwise overflow — the safest default for body copy. overflow-wrap: anywhere is more aggressive and also affects intrinsic sizing, which matters inside a flex or grid item that would otherwise refuse to shrink. word-break: break-all breaks anywhere regardless of need and is almost always too blunt for prose. hyphens: auto with a lang attribute adds real hyphenation where the browser has a dictionary. The structural half matters just as much: a flex or grid child defaults to min-width: auto, meaning "never shrink below my content", so long text forces the whole column open. Adding min-width: 0 is what actually lets the text wrap. Demo 20 is a live laboratory comparing all five strategies.

The mechanics are simple and the ethics are where teams get into trouble. Technically: render the deadline as a real <time datetime> element so the honest value is in the markup, compute remaining time from a server-provided timestamp rather than the visitor's clock, and update with a single setInterval that writes to a live region marked aria-live="off" — a countdown that announces every second is torture for screen reader users, so expose the deadline as text instead. Use font-variant-numeric: tabular-nums so digits do not jitter as they change. On the ethics: a countdown that resets when the visitor returns, or that counts down to a deadline which never arrives, is a dark pattern and is explicitly targeted by the EU Digital Services Act and the FTC's rules on deceptive urgency. If the sale genuinely ends Sunday, the timer is useful information. If it resets per session, you are manufacturing pressure, and increasingly that is a legal exposure rather than a growth tactic. Demo 02 ships the honest version.

Position communicates priority, and getting it wrong costs conversions in both directions. Top bars are for things that change the visitor's understanding of the whole page: an active sale, a shipping deadline, a service incident, a region or currency mismatch. They are seen immediately, which is the point, and also why an unimportant message at the top trains people to ignore the region entirely. Bottom bars suit anything that should not compete with the content on arrival — cookie consent above all, since it is a legal necessity rather than a message anyone wants, and bottom placement is now the convention precisely because it does not obstruct the first read. Inline banners, sitting in the content flow, are for context-specific messages: a stock warning next to the product, a validation error next to the field, an upgrade prompt next to the limit that was hit. The general rule is that the further a message is from its trigger, the more work the reader has to do to connect them. Never stack more than one persistent bar; two competing bars read as a broken site.

Yes, and banners are one of the few components where a mistake shows up directly in a Core Web Vitals score. Cumulative Layout Shift is the risk: a banner injected after first paint pushes the whole page down, and that is a textbook CLS failure. The fix is to reserve the space before the banner renders, or to use a sticky bar that participates in normal flow, or to animate it in with transform rather than by changing height. Every demo here follows one of those three. On accessibility, roles follow the interrupt/no-interrupt distinction described above, dismiss controls are real buttons with meaningful accessible names and at least 44 by 44 CSS pixel hit targets, focus rings are visible at 2px minimum with 3:1 contrast, and a dismissed banner returns focus somewhere sensible rather than dropping it to the document. Colour is never the only signal — every semantic state pairs its colour with an icon and a word, which is what makes success and error distinguishable to colour-blind users. All motion is guarded by prefers-reduced-motion: reduce, and any auto-dismissing message stays long enough to read or offers a way to keep it.

The eight pure-CSS banners port unchanged — copy the markup and the scoped .ba-NN rules and they behave identically anywhere. The twelve with JavaScript are all small, dependency-free init functions, and the porting work is lifecycle placement plus one architectural decision: banner visibility is state, so it belongs in your app's state layer rather than in a DOM class toggle. In React that means const [dismissed, setDismissed] = useState(() => localStorage.getItem(key) === '1') and conditional rendering, with useEffect only for the countdown interval and its cleanup — forgetting to clear that interval is the classic leak. Vue uses ref plus onBeforeUnmount, Svelte a store plus onMount returning cleanup. In the Next.js App Router these need 'use client', and consent banners specifically should render on the client only to avoid a hydration mismatch between the server's unknown state and the browser's stored choice. For Tailwind v4, colour and spacing map to utilities directly, while the keyframes, @property registrations and safe-area insets belong in a @theme block.