Your Marketing Site Is Not Responsive Just Because It Fits a Phone

A redesign can look excellent at every preset phone width and still fail at the lead form. If opening the keyboard hides the field error, traps the visitor inside a short panel or puts the submit button behind a sticky footer, the screenshot review approved the wrong thing. Approve the journey instead: can someone navigate to the form, recover from a mistake and submit it in the conditions where they will actually use the page?

The breakpoint review that misses the form

A typical review checks a desktop layout, a tablet layout and a couple of phone widths. The team adjusts cards, type and spacing until each screenshot looks right. Then a visitor taps a form field. The keyboard opens, the visible page becomes shorter, and a fixed call to action or consent banner occupies space the form needs. None of the width breakpoints changed, so none of the approved screenshots predicted the result.

This is not an argument against breakpoint reviews. They catch genuine layout problems. It is an argument against treating them as proof that an interaction works. Width, visible height and the ability to scroll to a control are different constraints. A narrow split-view window may make navigation or a multi-column form unusable because of its width. An on-screen keyboard may make the same form unusable because of its reduced visible height. A single mobile screenshot does not cover either interaction in full.

Set an acceptance condition that describes an outcome, not a composition: after opening the menu, can the visitor dismiss it and reach the form? After focusing each field, can they see what they are entering? After an invalid submission, can they find the error, correct it and reach submit? A call to action does not have to stay on screen while someone types. The visitor does need a workable route to the next action, without an obstructing overlay or trapped scroll.

What changes when the browser is in use

The distinction between the layout viewport and the visual viewport explains why a design can keep its breakpoint while losing usable space. The page can remain laid out against one area while the portion visible to the visitor becomes smaller. Since Chrome 108, Chrome on Android defaults to resizing the visual viewport rather than the layout viewport when the keyboard opens. Chrome specifically calls out fixed-position elements and viewport-relative sizing as things to check.

That matters for common marketing-page patterns: a fixed bottom CTA, a full-height hero, or a form placed inside a section with its own scrolling behavior. The keyboard can take away visible height without triggering a narrower CSS layout. If the form lives in an overflow-locked container, scrolling the document may not reveal the control the visitor needs. If a footer stays fixed over the form, the control may technically exist and still be impractical to use.

A split view is a different test. It can create a narrow or unusually short window, so check both navigation reflow and the vertical space left for menus and forms. An in-app browser is different again: it is a host environment, not merely a viewport preset. Site Seeing is useful for exploring awkward compositions, including keyboards, split views, in-app browsers and docked developer tools. Use it to find questions worth investigating, not to declare that your own site passes in a particular host app.

Browser zoom belongs in the review as well. It can expose assumptions about available space that the usual device presets leave untouched. The point is not to assemble an endless gallery of screenshots. It is to exercise the controls that turn a page view into a completed visit.

Test the conversion journey, not a screenshot

Pick one representative landing page and run a complete journey before approving its template. Start with the navigation. Open it, follow the intended route to the form, and check that it can be dismissed without covering the destination. Focus every input with the on-screen keyboard open. Submit invalid data, find the resulting error, correct it and submit again. Record whether each step remains possible, not just whether the page still looks orderly.

Run that journey at a narrow width and an unusually short height, in split view, at browser zoom and with the keyboard open. Check the states that static mockups tend to omit: an expanded menu, a long validation message, a consent banner awaiting a choice, a chat widget and a sticky CTA at the same time as the form. If two persistent controls compete for the bottom edge of the screen, identify which one should give way. Do not make the visitor solve the collision.

Use realistic CMS content during this review. A short headline and tidy form labels can make a component appear robust when campaign copy, a new block or a longer error message will change its height. Test at least the content variations your editors are expected to publish. An Astro or Next.js page assembled from approved headless-CMS components is still a page whose content changes after approval. Choosing between those frameworks does not remove the need to retest the resulting interactions.

Make the result observable. For each failed step, keep a screenshot or recording and note the browser and OS, viewport dimensions, keyboard state, content used and the control that could not be reached. Assign an owner. Without that context, a report that says “mobile form broken” is difficult to reproduce and easy to close after fixing only one manifestation.

Diagnose the failure before choosing a CSS fix

When a control disappears, first ask whether it is off-screen, behind another element or inside an area that cannot scroll. Inspect the relevant container’s overflow behavior, full-height sections, fixed headers and footers, and any overlay. Then check whether the layout viewport stayed the same while the visible area shrank. Those observations tell you whether the problem is a width constraint, a height constraint or a scrolling and stacking problem.

Resist the tempting one-line fix. CSS svh, lvh and dvh describe different viewport-sizing choices. Dynamic units can change as browser interface elements change, which can produce visible resizing or performance costs. Replacing vh with dvh on a hero may help a specific layout, but it is not a general remedy for an unreachable form. Test the affected journey before and after the change.

The viewport meta tag also offers interactive-widget behaviors: resizes-visual, resizes-content and overlays-content. Choosing a different behavior changes what the browser resizes; it does not automatically remove an obstructing footer or repair an overflow-locked form. VisualViewport scripting or a keyboard-specific API deserves consideration only after you have identified a browser and interaction that ordinary document flow and scrolling cannot handle. Otherwise, you add a browser-dependent moving part to a problem that may only need a simpler layout.

There are useful accessibility boundaries here, but do not turn them into a claim of full conformance. The W3C working draft explaining WCAG 2.2 Reflow discusses ordinary vertically scrolling content working without loss of information or functionality, or two-dimensional scrolling, at a width equivalent to 320 CSS pixels; content that needs a two-dimensional layout has exceptions. That is a reason to investigate narrow-window failures, not a claim that every page must fit every layout into a single column.

The draft explanation of Focus Not Obscured (Minimum) addresses keyboard focus entirely hidden by author-created content. Sticky headers, footers and banners can cause that failure. It does not say every CTA must remain visible throughout form entry. These linked Understanding pages are editor’s drafts; check the published WCAG wording before making a formal conformance claim.

Make responsive approval repeatable

Exploration and regression testing serve different purposes. Manual resizing and Site Seeing help discover combinations you did not anticipate. Playwright device emulation can vary device settings and use page.setViewportSize() to repeat a known journey at chosen dimensions. That is valuable for catching a reintroduced overlap or a menu that stops working at a tested size. Its viewport, user-agent and touch settings do not prove that a native keyboard opens the same way or that a particular in-app browser behaves identically.

For those risks, repeat important journeys on representative physical devices and inside the actual supported host apps. Chrome describes DevTools Device Mode as an approximation rather than code running on a mobile device, and recommends real-device testing when uncertain. Keep the automated checks, but do not let a green emulation run overrule a failed real interaction.

Use this approval checklist by page template, not just by launch campaign:

• Define the journey: navigation, form entry, invalid submission, correction and successful submission.

• Include narrow and short viewports, split view, zoom and the keyboard-open state. Record the actual browser, OS and host app where relevant.

• Check expanded menus, field and error visibility, scrolling, consent banners, chat widgets and sticky controls together.

• Test representative CMS copy, added blocks and realistic error lengths; repeat the checks when those templates or components change.

• Store a screenshot or recording, expected outcome and owner for each failure. Promote reproducible failures into automated checks where emulation can cover them.

• Require a physical-device or host-app check for keyboard and in-app-browser issues that emulation cannot establish.

If a rebuild is underway, the useful deliverable is not merely a responsive component library. It is a component, preview and acceptance-testing workflow that survives the next editor change and campaign launch. That is the point at which headless-CMS website development should account for these journeys, rather than treating the first set of approved screenshots as the finish line.