Mobile Consent Banners: The Small-Screen Compliance Problem
Most traffic is mobile and most consent banners are designed on desktop. On a phone screen, banners truncate text, push the reject button below the fold, and trap users in full-screen modals. Mobile consent needs its own design review, because the desktop banner does not survive the small screen intact.
What breaks on mobile
The most common mobile failure is truncation. A banner that reads beautifully on a 27-inch monitor collapses into three lines of cut-off text on a phone, with the privacy policy link and the reject button pushed out of view. The user sees "We use cookies" and an Accept button, and nothing else. That is not informed consent; it is a button with a fragment of context. Regulators increasingly test banners on mobile viewports, so the truncated banner is not just bad UX, it is a compliance exposure.
The second failure is the full-screen modal. Some banners expand to cover the entire phone screen, with no visible way to dismiss or scroll. On desktop the same modal is a polite centered box. On mobile it is a wall, and users tap whatever button is visible to make it go away, which is usually Accept. Consent obtained by trapping the user is not freely given, and a banner that functions as a wall on the majority of your traffic is a systemic problem.
The reject button below the fold
On desktop, accept and reject sit side by side. On mobile, the same layout stacks vertically, and the reject button lands below the fold inside a scrollable banner area. Users who never scroll the banner never see it. The design is technically symmetric, the code has both buttons, but the rendered result gives accept all the visibility and reject none. This is one of the most common mobile-specific findings in regulatory audits, precisely because it looks fine in the design review and fails in the viewport.
The fix is layout that is designed for the stack, not adapted from the row. Put accept and reject on equal footing in the mobile layout: same size, same visibility, both above the fold of the banner. If the banner must scroll, the choice buttons should be sticky, so the user can decide without hunting. Test the rendered banner on a real phone, not in a desktop browser's device preview, because previews do not catch the truncation that real font rendering produces.
Touch targets and fat-finger consent
Mobile consent has a physical dimension desktop does not: fingers. Reject and accept buttons placed too close together, or made too small, produce accidental consents. A user who meant to tap "Manage preferences" and hit "Accept all" because the buttons are 32 pixels tall and 4 pixels apart has not given valid consent. The accessibility guideline of 44-pixel minimum touch targets is a good floor for consent controls too.
This matters beyond usability. Consent must be an unambiguous indication of the user's wishes. A misclick is the opposite of unambiguous. If your analytics show a suspiciously high mobile accept rate relative to desktop, fat-finger consent is a plausible contributor, and it is worth checking the button geometry before celebrating the opt-in numbers.
Performance and pre-consent loading
Mobile also amplifies the pre-consent tracking problem. Banner scripts that load late on slow connections leave a window where tracking fires before the user has chosen. On desktop the window is small. On a 4G connection with a heavy tag manager, it can be seconds, and the majority of page loads happen in it. The consent state must gate the tracking, not race it, and the race is lost more often on mobile.
The mobile review checklist
First, load your site on a real phone and screenshot the banner: is the full text visible, are both buttons visible without scrolling, and is anything cut off? Second, tap every control and confirm the touch targets are large and separated. Third, time the banner against the tracking: does any non-essential script fire before the user chooses on a slow connection? Fourth, test the preferences center on mobile too, because the second layer usually breaks worse than the first.
Mobile is where most of your visitors meet your banner, so it is where your consent program is actually judged. Design for the small screen first, verify on a real device, and keep the choice as easy to make on a phone as it is on a monitor. The regulators already test this viewport. Your users live in it.