AEPD Cookie Banner Compliance: Reject Button Rules 2026

The rule in plain words

The AEPD updated its cookie guidance and the message is simple: rejecting must be as easy as accepting. One click for “Accept all”, one click for “Reject all”, at the same level, with the same visual weight, on the first screen the user sees.

That single rule explains almost every cookie banner change you have seen in the last two years. It also explains why so many sites still get it wrong.

A compliant banner gives the user three real choices on the first screen:

1. Accept all cookies.
2. Reject all cookies.
3. Manage preferences (granular control).

All three should sit in the same area, look like real buttons, and be reachable in a single action. No tricks, no hidden menus, no “X to close means accept”.

What this rules out

If your banner does any of the following, it is not compliant under current AEPD criteria:

• A giant green “ACCEPT ALL” button next to a tiny gray text link that says “Manage preferences” or “More info”.
• A “Reject” option that only appears after clicking “Configure”, forcing a multi-screen flow to say no.
• Pre-checked toggles for analytics, advertising, or personalization. The default state for non essential cookies is off.
• Wording like “By continuing to browse you accept our cookie policy”. Browsing is not consent. Scrolling is not consent. Closing the banner without choosing is not consent.
• Banners that come back on every page load until the user accepts. That is pressure, not consent.
• “Pay or OK” walls that force the user to either pay a subscription or accept all tracking. The European Data Protection Board considers this incompatible with valid consent in most cases, a pattern we cover in detail in cookie banner dark patterns in newspapers.

If you are not sure about your own banner, open it in a private window and try to reject everything. Count the clicks. If “Reject all” takes more clicks than “Accept all”, you have a problem.

The visual symmetry rule

The AEPD does not specify pixel sizes, but the principle is clear: a user looking at the banner for the first time should see “Accept” and “Reject” as equivalent options.

Practical checklist:

• Same button style for accept and reject. Same shape, same border radius, same height.
• Same area of the banner. Both visible without scrolling.
• Similar visual weight. If accept is a solid filled button, reject should also be a solid filled button. A solid green accept next to a ghost gray reject is not symmetric.
• Same level of menu. Both on the first screen. Reject does not live one click deeper than accept.
• Same language. If accept says “Accept all”, reject should say “Reject all”, not “Continue without accepting” or some softer phrase designed to nudge the user.

You can still highlight your preferred answer with color or contrast, but the difference cannot be so large that one option looks like the action and the other looks like a footnote.

Google Consent Mode v2

If you use Google Analytics, Google Ads, or anything from the Google tag stack, you need Consent Mode v2. The principle: load the tag in a denied state by default, and update only after the user accepts.

Set the default state before any Google tag fires. This usually means in the head, before GTM or GA4.

window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}

// 1. Set default state: ALL DENIED
gtag('consent', 'default', {
  'ad_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'analytics_storage': 'denied',
  'functionality_storage': 'denied',
  'personalization_storage': 'denied',
  'security_storage': 'granted'
});

// 2. Load GTM/GA4 after the default state is set

Only when the user clicks “Accept” do you trigger the update:

gtag('consent', 'update', {
  'ad_storage': 'granted',
  'ad_user_data': 'granted',
  'ad_personalization': 'granted',
  'analytics_storage': 'granted'
});

If the user rejects, do nothing. The default denied state stays in place and Google receives anonymous pings (modeled conversions) instead of full tracking. You keep some analytics signal without dropping cookies you do not have consent for.

A few things to verify in production:

• The default consent call runs before any Google script loads. If your tag fires first, you have already set cookies and Consent Mode cannot undo that.
• You store the user choice (in a first party cookie or localStorage) and replay the correct state on the next visit, so they do not see the banner again.
• The “Manage preferences” panel updates the same consent state, granular per category.

Accessibility requirements

A cookie banner blocks the page until the user interacts with it. That makes accessibility non optional. If a keyboard user or a screen reader user cannot dismiss the banner, they cannot use the site.

Minimum bar:

• Real <button> elements for accept, reject, and manage. Not <div onclick="...">. Buttons get keyboard focus and screen reader semantics for free.
• Visible focus ring when tabbing through the banner. If you removed the default outline, replace it with something visible.
• Logical tab order. Accept, reject, manage, close, in the order they appear visually.
• Color contrast of at least 4.5:1 for body text and 3:1 for large text and interactive elements, against the actual banner background.
• The banner is reachable in tab order without trapping the user. They should be able to tab into it, choose, and tab back out.
• A clear aria-label or visible heading like “Cookie consent” so screen readers announce what this dialog is.
• For modal style banners, use role="dialog" and manage focus on open and close.

WCAG 2.1 AA is the practical target. If you ship banners for clients, this is non negotiable.

Dark patterns to avoid

Beyond the obvious “Accept” being bigger than “Reject”, here are the patterns that get sites flagged:

• Pre-checked toggles in the preferences panel. Analytics off by default. Advertising off by default. Personalization off by default. The user opts in, not out.
• “Reject” hidden inside a submenu. If the user has to click “Configure” or “Manage” to find a reject option, the banner fails the equal ease test.
• Language manipulation. “Necessary cookies for the best experience” is not necessary, it is a marketing label. “Necessary” means strictly necessary for the site to function: session, security, basic preferences. Analytics is not necessary.
• Confusing button order. If accept is on the right one day and on the left the next, you are training muscle memory to click whichever the user expects, not whichever they want.
• Confirm shaming. “Are you sure you want to reject? You will miss personalized content.” This is pressure, not information.
• The “X to close” trap. Closing the banner without choosing should not count as consent. If you have no consent, you have no consent.
• Forced “Pay or OK” with no real reject. The user pays or accepts all tracking. The EDPB has been clear that this rarely produces valid consent.
• Hidden third party lists. The user agrees to “advertising partners” without seeing who those partners are. The list of vendors and purposes must be reachable from the banner.

If your banner uses any of these, you are not just risking a fine, you are training users to distrust your brand.

What you must log

The AEPD expects you to be able to prove consent. Practical implications:

• Store the user choice with a timestamp, the banner version they saw, and the categories accepted or rejected.
• Keep that record for the lifetime of the consent. If the user revokes, log that too.
• Make it easy for the user to revoke. A persistent link in the footer (often “Cookie preferences”) that reopens the banner.
• Re-prompt the user when the policy changes substantively, not on every visit.

Consent is not a one time event. It is a state you maintain.

Frequently asked questions

Is consent required for all cookies?

No. Strictly necessary cookies (session, login, security, basic preferences, shopping cart) do not require consent under the ePrivacy Directive and AEPD criteria. Everything else does: analytics, advertising, personalization, A/B testing, heatmaps, third party embeds that set cookies, and so on. When in doubt, treat it as needing consent.

What counts as a strictly necessary cookie?

A cookie is strictly necessary only if the service the user explicitly requested cannot work without it. A login session cookie is necessary. A CSRF token is necessary. A shopping cart identifier is necessary. Google Analytics is not. Hotjar is not. A “remember my preferred theme” cookie is borderline and usually requires consent unless the theme switch is the requested service.

Can I use a cookie wall?

A cookie wall (you must accept cookies to enter the site) is generally not compliant. Consent must be freely given, and forcing the user to accept tracking to access content is not free choice. The “Pay or OK” model is a softer version and the EDPB has rejected it in most contexts. Some news sites still use it, but expect that to change.

What logs do I need to keep?

At minimum: who consented (a user or device identifier), when, to which categories, and on which version of the banner and policy. Most consent management platforms (CMPs) handle this for you. If you build your own, store a record per consent event in a database you control.

Can I show the banner only once?

Yes, that is the goal. Once the user has chosen, store the choice and do not re-prompt on every visit. Re-prompt only when the policy changes in a way that affects the categories or vendors. A small persistent link (footer or settings) lets users change their mind without you nagging them.

What happens if the user does nothing?

Nothing. No consent means no non essential cookies. You serve the site, the strictly necessary cookies work, and analytics, advertising, and personalization stay off. Treat “no answer” as “no consent”. Do not assume, do not default to accepted, do not count silence as agreement.

Does this apply to my site if I am outside Spain?

If you have users in Spain or in the EU, yes, GDPR and the technical security requirements that go with it apply. The AEPD is the Spanish authority, but the underlying rules are European. A site based in Mexico or Argentina that has Spanish or EU visitors needs to comply for those visitors.

Build it once, build it right

A compliant cookie banner is not complicated. It is a small piece of UI that respects three rules: equal ease for accept and reject, no pre checked categories, and a clear way to change your mind later. Add Consent Mode v2 if you use Google tools, make the banner keyboard accessible, and log the consents.

Ship it once, in good faith, and you stop worrying about it. Try to game it, and you spend the next two years rewriting it every time the AEPD or the EDPB tightens the screw.

For complete ethical data management, see how to implement Global Privacy Control (GPC) and how to secure your stack under GDPR Technical Security.