# Consent Banners on Mobile: The Bottom Sheet Problem Nobody Tests

Source: https://cookieaegis.com/blog/2026-11-04-consent-banner-mobile-bottom-sheet.html

[Home](../index.md) / [Blog](index.md) / Consent and Live Chat Widgets: The Tracker Hiding in Your Support Tool


Published 2026-11-04

On mobile, a consent banner is usually a bottom sheet covering the lower third to half of the viewport, exactly where thumbs, sticky add to cart bars, and chat widgets already live. If reject takes one more tap than accept on that sheet, or the sheet traps scrolling until a choice is made, the consent you collect on phones is the weakest consent you hold.

## The layout collision comes first

Open your own store on a phone and count what competes for the bottom of the screen: the consent sheet, a sticky buy bar, a chat bubble, sometimes a promo strip. Each was designed alone. Together they stack, overlap, or push the consent choices partly off screen, and a reject control that sits under another element is a reject control that does not exist for the person trying to tap it.

Viewport units make it worse. A sheet sized in viewport height changes size as mobile browsers collapse their address bars during scroll, so the banner can jump mid interaction. Test with the browser chrome moving, one handed, on a mid range Android device rather than the flagship on the office desk, because that is the hardware most of the traffic actually uses.

## Equal prominence is harder on a small screen

Regulators read mobile banners the same way they read desktop ones: refusal must be as easy as acceptance. On a sheet, the failure pattern is specific. Accept is a full width filled button in the thumb zone. Reject is a text link above the fold of the sheet, or behind a settings step, or in a colour that reads as disabled. The desktop version of the same banner often passes, which is why the finding surprises teams who only ever audited the desktop build.

Check the second layer too. If managing choices opens a panel that scrolls inside the sheet, the save control must stay reachable while the toggles scroll, and the toggles themselves need tap targets a thumb can hit without catching the neighbouring row. Our piece on [Testing Consent Mode in the Denied State, Not Just the Granted One](https://cookieaegis.com/blog/2026-11-03-consent-mode-denied-state-testing.md) covers the desktop denied state test this mobile check extends.

## A five minute mobile consent check

Use a fresh private window on a real phone. The sheet should appear without covering its own controls, both primary choices should be visible without scrolling the sheet, and rejecting should take the same number of taps as accepting. Then reload: the choice must persist and the sheet must stay away. Finally, with consent denied, browse two pages and confirm no marketing tags fire, using the same network check you run on desktop.

Record the screen while you do it. When a vendor insists their template is compliant out of the box, a twenty second recording of a reject button hidden under a sticky cart bar ends the discussion faster than any clause in the contract.

Keep reading: [Testing Consent Mode in the Denied State, Not Just the Granted One](https://cookieaegis.com/blog/2026-11-03-consent-mode-denied-state-testing.md) [Your Redesign Changed Your Cookies. Rescan Before You Announce It.](https://cookieaegis.com/blog/2026-11-03-cookie-scan-after-redesign.md) [Cookiebot Alternatives for 2026](https://cookieaegis.com/blog/2026-11-02-cookiebot-alternatives-2026.md).

## Frequently asked questions

### Why does our banner look fine on desktop but broken on phones?

The mobile template is a separate layout, usually a bottom sheet, with its own stacking order against sticky bars and chat widgets. Desktop audits never load it. Test consent on a real phone in a private window, including the settings layer and a reload after choosing.

### Can a mobile consent banner block scrolling until a choice is made?

Blocking interaction until a choice is made is treated as forced action by several European regulators, and it also breaks the equal prominence test when the blocked page pressures a fast accept. A sheet the reader can dismiss or scroll past while deciding is the safer pattern.

### How big should mobile consent tap targets be?

Use at least the platform guidance of roughly 44 to 48 pixels for each control, with spacing so adjacent toggles do not overlap. On a consent panel, a missed tap that flips the wrong toggle is not a usability footnote; it records a choice the person did not make.

### Does rejecting on mobile need the same taps as accepting?

Yes. The standard regulators apply is that refusal must not take materially more effort than acceptance. If accept is one tap on the sheet and reject is a tap into settings plus a save, the banner fails that standard on the device most visitors use.