Auditing the Mobile Banner: When Consent Covers the Whole Shop
On a small screen a compliant sized banner becomes a full page wall with the reject option below the fold. Mobile specific consent failures and how to test them on real viewports.
On desktop the banner is a modest strip along the bottom. On a 360 pixel phone it is the entire shop: logo peeking above it, product nowhere, and two buttons, one of which, the one that says no, sits below the visible area or behind the safe area of the phone, reachable only by a scroll the banner itself does not hint at.
Mobile is where consent design stops being a legal abstraction. The same configuration passes a desktop review and functions as a forced choice on the device most of your traffic uses. This post covers the mobile specific failures, viewport coverage, unreachable reject options, sticky reappearance, and the device based test that catches them.
Coverage is a consent issue, not a design taste
A banner occupying most of a small viewport, that cannot be dismissed without answering, converts a legal choice into a toll gate. Regulators assessing dark patterns look at whether rejecting is as easy as accepting, and a reject control rendered off screen, shrunk, or placed where the phone's own interface elements cover it fails that comparison in the most literal way possible. Test at 360 and 390 pixel widths, in portrait, with the browser chrome visible, because that is the geometry your visitors get, not the clean emulator frame in a design tool.
Watch for the second offence: the banner that returns on every page because the dismissal was stored in a cookie the phone's browser restricts or the app container clears, training visitors to tap accept just to make it stop. Repeated nagging until yes is a named dark pattern in European guidance, and mobile storage limits manufacture it accidentally.
The on-device checklist
Use two real phones if you can, one iOS, one Android, because safe areas, browser bars, and cookie behaviour differ. On each: can the whole banner be seen, can reject be reached without scrolling inside the banner, does the banner block the page's own sticky add to cart or checkout button after dismissal, and does the choice persist across three page views and a return visit the next day. Screenshot each state at the real viewport size; the screenshots are the audit evidence and they are unarguable.
Include the landscape case and the small tablet if your analytics show them, and check the banner inside any in-app webviews you advertise in, because social app browsers have their own viewport quirks and a banner that behaves in Safari can cover the checkout button entirely inside an app.
Related reading: Auditing Consent When Checkout Moves to a Third Party Page, Auditing Consent Banners on Mobile Layouts Where Space Runs Out, Auditing Consent Banner Dark Patterns Honestly.
Frequently asked questions
How much of a mobile screen may a consent banner cover?
There is no percentage in the law, but the operative test is whether both choices are genuinely available and equally easy. A banner that hides the reject option below the fold or under device interface elements, or that blocks all use until answered, fails the fairness comparison regulators apply, whatever its desktop appearance.
Why does our banner reappear on every mobile page view?
Usually because the consent cookie is not persisting: browser storage restrictions, an app webview clearing state, or a cookie set for a path or domain that does not match the rest of the site. It reads to visitors as nagging until they accept, which is treated as a dark pattern even when it is a bug.
Should we test consent in emulators or on devices?
Emulators catch layout problems at set widths and are fine for routine checks. The release level audit should include at least one real iOS and one real Android device, because safe areas, dynamic browser bars, and cookie behaviour are device realities that emulators approximate imperfectly.
Does a sticky mini banner after dismissal cause problems?
A small, non blocking reopener that lets visitors revisit their choice is good practice and in some interpretations expected. It becomes a problem when it covers purchase controls, follows the scroll over checkout elements, or is visually styled to be mistaken for part of the shop rather than a privacy control.