Customizing the consent banner

Open the customizer

Open your site and go to Banners → Consent banner → Edit. The customizer takes over the full screen, with your settings in a tabbed rail — Content, Design, Categories, Blocking, and Behavior — on one side and a live preview on the other. The preview draws both screens, the banner in the layout you picked and the preference center, with your copy and colors, and it draws every choice as the same button the live banner does. Switch it between the two screens, between desktop and mobile, and between light and dark, before you trust any change.

Everything you do here is a draft. The live banner does not change until you publish.

Pick a layout

There are five: a box in the bottom-left or bottom-right corner, a bar across the bottom or top, and a centered modal.

On the banner’s first screen, only the centered modal claims aria-modal, because only the modal backs that claim with a real focus trap. Keyboard focus stays inside the dialog until the visitor acts. The other four layouts sit alongside the page, so announcing them as modal to a screen reader would be a lie. We would rather claim less and have it be true.

Set the theme

You control the accent, background, and text colors, plus the corner radius. Dark mode has three settings: follow the visitor's system preference, always light, or always dark. The dark palette is derived from your colors. You do not maintain a second theme.

The accent picker shows a live contrast readout as you drag. The accent fills every consent choice, and the label on it is white or near-black, whichever has more contrast against your accent. Each choice also has a 1px edge: the accent itself when it stands out from the banner background by 3:1, otherwise the closest shade toward your text color that does. The readout checks the label once, because it sits on the accent in every mode, and the edge once for each palette your dark-mode setting can show: both when the banner follows the visitor's system, one when it is fixed. It warns you when the label drops below 4.5:1, the level text needs to stay readable, or an edge drops below 3:1. You can publish anyway, but the warning is there because an unreadable Reject button is a consent problem, not just a design one.

What you cannot change

Accept and Reject render as the same button in every layout: the same accent fill, label color, edge, size, and weight. The preference center's Allow all, Reject all, and Save choices match them, and Reject all is always there, so turning every optional category off takes one click on either screen. When the banner opens, neither choice has focus. None of this is a setting, and that is deliberate: an accent-colored Accept beside a plain Reject is the pattern regulators single out, and making it configurable would mean letting you configure it. We chose not to.

The one way around it is Custom CSS, at the bottom of the Design tab. UserGuard adds it to your page as written. It is not scoped to the banner, so start selectors from #ug-banner, and it needs !important, because the banner styles its elements inline. A rule aimed at one button leaves the others behind. Every choice carries the class ug-choice and a data-ug-action attribute (accept, reject, or save), so if you restyle one, select them together with #ug-banner .ug-choice. The Preferences button has data-ug-action="preferences" but is not a choice.

Edit the copy

You can rewrite:

• The preference center copy, including its Allow all and Reject all buttons. Leave Allow all empty to hide it; Reject all always shows, and left empty it uses your Reject wording.
• Category names and descriptions — say what "Analytics" actually means on your site.
• The cookie policy link.
• The re-open control: its corner and its label.

The re-open control always renders. After a visitor consents, it is how they change their mind, and withdrawal has to be as easy as consenting was. You choose where it sits and what it says; you do not choose whether it exists.

Withdrawing does more than stop the next page load. When a visitor turns a category off, UserGuard deletes the cookies in that category that it can reach, matched by name against your approved inventory, so nothing unrelated is touched. Two kinds it cannot reach, and does not pretend to: cookies marked HTTP-only are invisible to any script, and a cookie set on a third party's own domain belongs to that domain, where only the browser or that vendor can remove it. What it can clear, it clears, on the spot and again on the next page view in case anything slipped through.

Set the behavior

Two settings live on the Behavior tab rather than with appearance:

• Default consent model — what happens when a visitor cannot be placed in a jurisdiction. Opt-in fails closed: no consent, no cookies. Opt-out allows cookies until the visitor objects. Notice-only renders a dismissible notice bar and records the dismissal, so even the lightest mode leaves evidence.
• Re-consent interval — how many days a consent stays valid before the banner asks again, from 0 to 730.

Publish, and what publishing means

Publishing is versioned and immutable. Each publish creates a numbered banner version that can never be edited afterward, only superseded by the next one. Every consent record names the exact version that was on screen when the visitor acted.

This is the point of the whole workflow. If a consent is ever questioned, "what did the visitor actually see" is answerable from the record, not reconstructed from memory. Draft freely; the preview costs nothing. The version history starts when you publish.