Consent Banners on Mobile: The Bottom Sheet Problem Nobody Tests
Desktop consent testing happens on a large monitor with a mouse that can reach anything. The visitor's reality is a phone held in one hand, a banner sheet anchored to the bottom, and a reject option that may sit under a keyboard, behind a chat widget, or off the visible area entirely in landscape.
Mobile is also where most traffic now arrives for many sites, which makes the pattern strange: the surface with the most consent events gets the least consent testing. The failure modes below are not exotic. They show up on ordinary sites with reputable tools.
Where the sheet breaks
The keyboard collision is the classic. A banner with a settings or search field, or a page form behind it, summons a keyboard that halves the viewport. Sheets that are positioned against the full screen height then strand their buttons under the keyboard, and the only reachable action is accept. Regulators read that pattern as a dark pattern whether or not anyone designed it that way.
In-app webviews are the second blind spot. Traffic from social and email apps often renders inside a stripped webview with different viewport behavior, no extensions, and sometimes older rendering engines. A banner tested only in mobile Safari and Chrome may be unusable in the exact context a campaign sends people into.
Reach, order, and the landscape case
One thumb operation puts the easy zone at the bottom of the screen, which is why the sheet pattern exists. But stacking accept above reject in a tall sheet can push reject below the fold of the sheet itself, requiring a scroll inside a banner, a step almost nobody takes. Keep both primary choices visible without scrolling, in both orientations, at the smallest common viewport height.
Landscape gets skipped because analytics say little traffic uses it. Consent law does not grade on traffic share. If the banner is broken in landscape, it is broken for the people who hit it there, and video heavy sites have more landscape mobile use than their teams assume.
A test pass that fits in an afternoon
Use two real devices, one iOS and one Android, not only emulator profiles. Run the banner in the browser, in one social app webview, portrait and landscape, and with the keyboard forced open. Record the screen while a colleague who has never seen the site tries to reject all cookies one handed. The recording will find more than any checklist.
Log what you tested, tool version and date included. When a complaint arrives, a contemporaneous test record is evidence of a working program in a way that a post complaint fix never is.
Related reading
These earlier guides cover connected questions in more depth: First-Party Cookies Still Need a Consent Decision, Consent Banners on Mobile: The Bottom Sheet Problem Nobody Tests, and Consent and A/B Testing Tools: The Variant Cookie That Fires Before the Choice.
Frequently asked questions
Is a bottom sheet banner legally riskier than a center modal?
The format itself is neutral. Risk comes from what the format does to the choices: hidden reject paths, scroll dependent buttons, or keyboard collisions. A sheet that keeps reject as visible and reachable as accept is as defensible as any modal.
Do we need to test in-app webviews separately?
Yes. Webviews in major social and mail apps differ in viewport sizing and script behavior from standalone browsers. If a meaningful share of your traffic arrives through them, they are part of your consent surface.
What viewport sizes should we test?
Cover the small end first: around 360 by 640 CSS pixels and the shortest landscape height your analytics show. Small screens expose stacking and reach problems that larger test devices hide.
Should the banner pause page interaction on mobile?
Blocking modals raise the dark pattern stakes because the cost of refusing rises. If you block, the reject path must be exactly as fast as accepting, one tap, no scroll, no settings maze.