The second layer is where consent gets real

The first banner asks a yes-or-no question. The preferences center is where a visitor says which purposes they'll allow and which they won't, and it's the panel most teams design last and test least. That's a mistake. If someone opens "Manage preferences" and can't tell analytics from advertising, can't work the toggles with a keyboard, or can't find the button that saves their choice, you've collected a decision that isn't specific or informed. Under the GDPR, consent has to be exactly those things.

This guide is about the panel itself: how to group purposes, how to build a toggle people can see and operate, what the default state should be, and which buttons belong at the bottom. For the broader accessibility rules that apply to the whole consent UI, read Cookie Banner Accessibility first.

Group by purpose, not by vendor

A visitor doesn't think in terms of the forty scripts on your page. They think about what's being done with their data. So group toggles by purpose: strictly necessary, functional or preferences, analytics or performance, and advertising or marketing. That structure mirrors how regulators and the IAB frame purposes, and it keeps the list short enough to scan.

Under each category, name the vendors or list them behind a "See details" disclosure. Don't invert it. A flat list of ad-tech domains with a switch next to each isn't granular consent, it's a wall that pushes people to hit "Accept all" just to escape. Keep the top level to four or five purposes, with detail available on demand.

The toggle: a control people can actually operate

The switch is the heart of the panel, and it's where accessibility quietly breaks. A few rules make it work for everyone:

Use a real control. A native <input type="checkbox"> is the safest choice: it carries the right role, keyboard behaviour, and state for free. If you build a custom switch, give it role="switch" and keep aria-checked in sync so its on/off state is announced.
Label it, don't just colour it. A green pill and a grey pill mean nothing to a colour-blind user or a screen reader. Pair every switch with a text label and an announced state, and make sure the label is clickable so the hit area is generous.
Size the hit area. WCAG 2.2's Target Size (Minimum) asks for a target of at least 24 by 24 CSS pixels, or smaller with enough spacing around it. A tiny toggle on a phone fails real thumbs.
Handle the always-on case honestly. Strictly necessary cookies don't need consent, so their toggle is on and can't be turned off. Show it as on and disabled, and say why in a short line. Don't hide it, and don't fake a working switch that snaps back.

<!-- A native checkbox is the most reliable accessible toggle -->
<div class="consent-row">
  <input type="checkbox" id="cat-analytics" name="analytics" />
  <label for="cat-analytics">Analytics</label>
  <p id="desc-analytics">Helps us count visits and see which
     pages are used. No advertising.</p>
</div>

<!-- Strictly necessary: on, and clearly not changeable -->
<div class="consent-row">
  <input type="checkbox" id="cat-necessary" checked disabled
         aria-describedby="desc-necessary" />
  <label for="cat-necessary">Strictly necessary</label>
  <p id="desc-necessary">Always on. Needed for the site to work.</p>
</div>

Every non-essential category starts off

Toggles for analytics, advertising, and anything beyond strictly necessary must default to off. A pre-checked box isn't consent. The Court of Justice of the EU settled this in the Planet49 case: a pre-ticked checkbox doesn't give valid consent, because consent has to be an active choice. If your panel opens with everything already enabled, a visitor who hits "Save" has agreed to nothing on purpose, and you've built a dark pattern into your most detailed screen.

The full reasoning is in Why Pre-Ticked Boxes Invalidate Consent. The design rule is short: off by default, and let the visitor turn things on.

Write a label and a plain description for every category

Each category needs a name a person recognises and one sentence saying what it does. "Analytics: helps us count visits and see which pages people use" tells someone what they're agreeing to. "Performance and measurement cookies (see policy)" tells them nothing. Skip the jargon, name the actual purpose, and keep it short. Our guide to consent copy goes deeper on wording, and clear descriptions tend to raise opt-in rates because people trust what they understand.

The buttons at the bottom decide everything

A preferences panel usually offers three actions: save the current selection, accept everything, and reject everything. Two design points matter more than the rest:

Keep reject as easy as accept. If "Accept all" is a bright filled button and "Save my choices" or "Reject all" is a faint text link, you've tilted the choice. The EDPB's guidance on deceptive design patterns treats that imbalance as a problem for freely given consent. Give the options equal visual weight.
Make "Save" mean what it says. The button that saves the current toggle state should be labelled for what it does ("Save my choices"), not something vague like "OK" or "Confirm" that a screen-reader user hears out of context.

More on the balance in Cookie Consent UX Patterns.

Focus and keyboard behaviour when the panel opens

Opening the preferences center is a state change, and keyboard and screen-reader users need to be brought along. When the panel opens, move focus into it, to the heading or the first control, so it's announced instead of appearing silently. If it's a modal panel over the page, trap focus inside it while it's open and return focus to the button that opened it when it closes. Every toggle and button must be reachable with Tab and operable with Enter or Space, in an order that matches the visual layout. A panel you can open with a mouse but can't complete with a keyboard is worse than no panel at all.

Give people a way back in

Consent isn't a one-time event. People change their minds, and the law expects withdrawal to be as easy as granting was (consent withdrawal covers the requirement). That means a persistent, reachable entry point to reopen the preferences center, usually a "Cookie settings" link in the footer or a small floating control. Make sure it's in the tab order, has a clear accessible name, and doesn't sit on top of other focused content when a keyboard user tabs to it.

Accessible preferences center checklist

Group toggles by purpose, four or five categories at the top level
Vendors live behind a details disclosure, not as a flat wall of switches.
Use native checkboxes, or role=switch with aria-checked kept in sync
State must be announced, not signalled by colour alone.
Default every non-essential category to off
Pre-checked isn't consent, per the CJEU Planet49 ruling.
Show necessary cookies as on and disabled, with a reason
Don't fake a switch that can't actually turn off.
Give every category a plain-language name and one-line description
Name the purpose, drop the jargon.
Keep save, accept, and reject at equal visual weight
An easy accept and a buried reject is a deceptive pattern.
Move focus into the panel on open and return it on close
Operate every toggle and button by keyboard, in logical order.
Provide a persistent, reachable way to reopen preferences
Withdrawal has to be as easy as consent was.

Where CookieBeam Fits

CookieBeam banners include a per-category preferences panel you can configure: category names, descriptions, and button text are all editable, so you can write plain labels instead of fighting a fixed template, and set colours and sizes that meet the contrast and target-size thresholds. Non-essential categories are off until the visitor turns them on, and the panel is operable by keyboard with real semantics, so the choice you record is one the visitor actually made.

Related guides

Pair this with Cookie Banner Accessibility and Cookie Banner Copy That Increases Consent. For the standards behind the toggle, see the W3C's ARIA switch pattern and Target Size (Minimum).