Why does a consent banner reappear on a subdomain?

Usually because the consent cookie was set as host only, so other subdomains cannot read it, or because the CMP is configured differently on that host. Each subdomain looks correct alone, which is why a cross domain test with one browser session is needed to find it.

What cookie scope lets subdomains share consent state?

The consent cookie generally needs its domain attribute set to the registrable domain, with appropriate path and security flags, so sibling subdomains can read it. Exact configuration depends on your CMP and security policy, and should be tested in production.

Should every subdomain show the same banner?

The experience should be consistent, but the key requirement is shared state, not identical pixels. A visitor's recorded choice and preferences must be readable and honoured on every host they reach in a session.

How often should cross subdomain consent be audited?

After any CMP, checkout, or domain change, and on a recurring automated check. Deployments on a single host are the common trigger for a break that only appears when a visitor crosses between subdomains.

Auditing the Consent Banner Itself for Keyboard Traps

November 1, 2026

The banner demanding an accessible website is often the least accessible element on it: focus that never arrives, traps that hold it, and refuse buttons a keyboard cannot reach.

There is an irony auditors keep finding and it never gets less pointed. A store commissions accessibility work, and the most inaccessible element on its homepage is the consent banner: a dialogue that appears without moving focus to itself, or that traps focus with no escape, or whose refuse option sits three layers deep for a mouse and effectively at infinity for a keyboard.

The banner is a modal in everything but implementation quality. It interrupts, it demands a decision, and it overlays the content the shopper came for. It should be built and audited like a modal, with the same focus discipline as a checkout drawer, and it almost never is, because it arrives as a third party script the store treats as someone else's code.

The four failures to test for

First, arrival. When the banner appears, keyboard focus needs a way in that does not require tabbing through the entire page behind it. Some banners insert themselves at the end of the DOM, so a keyboard user meets them after the footer, minutes into the page. Second, containment while deciding is fine, escape is not guaranteed: the banner that swallows the escape key and every tab stop outside itself, while offering buttons a keyboard cannot activate, is a trap with a privacy policy.

Third, the return. After the shopper answers, focus should go somewhere sensible, ideally back to where it was, not reset to the top of the page. Fourth, parity of options: accept, refuse, and manage preferences must all be reachable and operable by keyboard, in a sensible order, with visible focus. If accept is a button and refuse is a styled span that only a mouse can trigger, the audit finding writes itself, and it will mention dark patterns as well as accessibility.

Vendor code is still your audit result

The usual defence is that the banner is the consent platform's product and its accessibility is their responsibility. Contractually, maybe. The shopper and the complaint will name the store. So test the banner as shipped, with your configuration, because configuration changes behaviour: position, layers, the custom buttons and second layer views are yours, and a platform that is accessible in its default skin can be made inaccessible by a store's custom template in an afternoon.

Report findings to the vendor with the keyboard evidence attached, steps and screen reader output, and record their response in the audit. Vendors fix documented failures from named customers. What they cannot fix is a store that never tested the banner because it assumed someone else had.

A ten minute banner protocol

Load the homepage fresh. Do not touch the mouse. How many tabs until the banner is reachable. Can every option be activated. Does escape do anything, and should it. After answering, where is focus. Repeat with a screen reader and listen to whether the banner announces itself as a dialogue with a label a person would understand. Ten minutes, five answers, and the most interacted-with component on the site has had its first accessibility review.

Frequently asked questions

Is a consent banner required to be keyboard accessible?

It is part of the web experience the store is responsible for, and the same WCAG expectations apply to it as to any modal: reachable focus, operable controls, visible focus, and a sensible focus return after it closes.

What is the commonest banner accessibility failure?

Focus that never reaches the banner in reasonable order, often because it sits at the end of the DOM, followed by refuse or preferences options that a keyboard cannot activate at all.

If the banner is a vendor product, whose problem is it?

The store's, in front of shoppers and regulators. Configuration is the store's own work and can break a sound default. Test it as shipped and report documented failures to the vendor.

How long does a banner keyboard audit take?

About ten minutes: tab count to reach it, operability of every option, escape behaviour, focus position after answering, and one screen reader pass for how it announces itself.