Cookie banner on mobile: layout, tap targets and accessibility

On a phone, a cookie banner should be a short panel at the bottom of the screen, not a full-screen wall: a two- or three-line text, Accept all and Reject all side by side or stacked with the same size, and Customize just below, all within reach of the thumb. Each button needs a tap target of at least 24 by 24 CSS pixels under WCAG 2.2, and 44 by 44 is the comfortable size. The banner must not hide the element that has keyboard focus, must work when the visitor zooms text, and must leave the page readable behind it. Most consent traffic is mobile, so this is where the design of the choice is decided.

Why is mobile harder?

Space. A banner that takes a fifth of a laptop screen can cover the whole viewport of a phone. Designers then cut text, shrink the Reject button or hide it behind "Settings", and the result fails the rule European authorities apply everywhere: refusing must be as easy as accepting. The EDPB cookie banner taskforce agreed that a banner with an accept button and no reject option on the same layer is an infringement for a vast majority of authorities, and a reject option that is technically present but tiny or below the fold invites the same finding.

Which layout works on phones?

Google's Search documentation on intrusive interstitials exempts interstitials shown because of a legal obligation, but still recommends banners that take a small fraction of the screen over full-page interstitials, and warns against redirecting every URL to a consent page. A bottom sheet also lets visitors see what they are deciding about.

How should the buttons be arranged?

• Equal weight. Accept all and Reject all with the same size, shape, font weight and readable contrast. If one is filled, both are filled, or both outlined. See the Reject all guide.
• Side by side or stacked. Two buttons of equal width side by side fit most phones in English; in German or French the labels often need stacking. Stack them with the same width rather than shrinking text.
• Thumb reach. The lower part of the screen is the easiest to reach with one hand. A bottom sheet puts the buttons there naturally.
• Customize as a third option. A text button or secondary button below the main pair opens the preferences.
• No close cross that means accept. If there is a close control, it should either be absent or count as a refusal, and the text should not suggest otherwise.

How big should tap targets be?

WCAG 2.2 success criterion 2.5.8, Target Size (Minimum), at level AA, requires pointer targets of at least 24 by 24 CSS pixels, unless undersized targets are spaced so that a 24-pixel circle around each does not touch another target. Success criterion 2.5.5, Target Size (Enhanced), at level AAA, asks for 44 by 44 CSS pixels. Use 44 pixels of height for the main buttons and at least 8 pixels between them; toggles in the preferences panel need the same care, including the label being tappable.

What accessibility rules matter most on mobile?

• Focus not obscured. WCAG 2.2 success criterion 2.4.11 (AA) says a component receiving keyboard focus must not be entirely hidden by author-created content. The W3C's explanation names sticky cookie banners as a typical failure, and lists passing approaches: making the banner modal, adding scroll padding so it does not cover content, or closing it when it loses focus.
• Reflow. Success criterion 1.4.10 asks that content work at a width of 320 CSS pixels without horizontal scrolling. Test the banner at that width with long translations.
• Text resize. When the visitor enlarges text in the system settings, the banner must grow and scroll inside itself rather than push the buttons off-screen.
• Screen readers. The banner needs a heading or label, buttons that are real buttons, and toggles with names and states. The accessible cookie banner guide covers the full checklist.

How much text fits?

About 40 to 60 words on the first layer, which is two to four lines on a phone. Name the purposes ("measure visits", "show ads") and the main partners, and link to the cookie policy. Put the details, the category descriptions and the cookie table in the preferences panel, which can take the full height and scroll. Cookie banner text examples has short versions ready to use.

The preferences panel on a phone

Open it as a full-height sheet with its own scroll, the Save button fixed at the bottom, and Reject all and Accept all repeated there so visitors do not have to toggle each category. Categories start off. Collapse the cookie table under each category so the panel stays readable.

How do you test it?

Use real devices, not only the browser's device emulation: a small Android phone, an iPhone with a notch, and a tablet. Check portrait and landscape, system text at 200%, a screen reader (TalkBack or VoiceOver), and the slowest network you can, since a banner that appears late and shifts the layout leads to accidental taps. Then repeat the DevTools test from checking cookies before consent on mobile emulation.

Using a ready-made banner

Cookiequiet's banner offers three layouts (bar, floating box and centered modal), with Accept all and Reject all of the same size and weight on the first screen, keyboard and screen-reader support, and rendering in a shadow root so the site's CSS cannot break it. Setup is one script tag before your other scripts, with Reject all on by default, about five minutes from sign-up to a live banner; the free plan covers one website with unlimited pageviews.