Record the page version, viewing area and zoom setting before judging the layout. “Looks fine on mobile” does not tell another person which content was checked or how to repeat the check.
Choose one visitor task. Read the page at a narrow width, enlarge it with browser zoom and inspect the information and controls that task needs. Keep a specific issue and recheck record.
For a ClickFunnels AI project, this gives the builder a bounded review to perform. It does not prove how a generated page behaves or grant access to build or publish it. Use the ClickFunnels AI agent guide for current workflow and access requirements.
List the content the task depends on
For a service-enquiry page, the list might be the service description, limitations, comparison, enquiry fields and action. Include the route back to service details if someone needs to reconsider a choice.
Inspect the actual page and its relevant states. A closed menu, an open menu and a form showing a correction can occupy space differently. Do not claim the error state was checked if you never reached it.
Set a stopping point before using controls. A page can be inspected without sending a request. If submission may create a record or send a message, confirm the permitted environment and effects before testing it. Leave that part NOT RUN when its authority or behavior is unresolved.
Use configurations someone can reproduce
A viewport is the browser's content viewing area, not simply the monitor's physical width. Browser zoom and mobile pinch zoom can affect layout and visible areas differently. Record which method you used and the measured CSS-pixel viewport, rather than relying on a device name. MDN's viewport explanation
For ordinary vertically scrolling content, WCAG's Reflow criterion uses a width equivalent to 320 CSS pixels. A 1280 CSS-pixel starting viewport at 400% browser zoom is an equivalent configuration. It concerns preserving information and functionality without two-direction reading, with exceptions for content needing a two-dimensional layout. W3C's Reflow explanation
A useful review plan can include these separate records:
Scroll horizontally to compare all columns.
| Record | Proposed configuration | What to record when executed |
|---|---|---|
| V01 | Desktop baseline at 100% browser zoom | Actual content viewport width and height; page version |
| V02 | 390 CSS-pixel narrow viewport at 100% | Actual width/height and how the narrow view was produced |
| V03 | 320 CSS-pixel narrow viewport at 100% | Actual width/height; any content or action lost |
| V04 | 1280 CSS-pixel starting viewport, then 400% browser zoom | Starting and resulting measured viewport, zoom method and result |
The 390px check is useful additional coverage; it does not replace V03. Keep V03 and V04 separate even when their resulting widths match. If your environment cannot produce or verify a configuration, record that limitation instead of inventing a result. This plan focuses on vertically scrolling pages, not every writing direction or interface.
Follow four fictional layout cases
Imagine a garden-care enquiry page, version A. It contains ordinary text, a service comparison table, a fixed invitation banner and a link back to the service details. The following conditions are invented review scenarios. No actual browser test or CFAI page inspection was performed; all execution results are NOT RUN.
R01: Ordinary copy extends beyond the reading area
Assume a long reference string makes the enquiry panel too wide at V03. The explanation beside it now requires moving sideways to finish each line.
Record the reference string and the exact surrounding text that becomes difficult to read. The problem is more specific than “the page scrolls.” Ask the implementer to preserve the full information while making the ordinary copy readable in the intended area. A clipped string with no usable way to read it would leave the information problem unresolved.
After a change, repeat V03 from the same page state. Check the reference, the explanation and the nearby enquiry action. Then repeat the other configurations the change could affect.
R02: A banner covers the action
Assume the invitation banner occupies enough space at V04 that the enquiry action stays covered even after the visitor scrolls to it.
Name the obstructing banner and the action it covers. Record the zoom and viewport height as well as width. A layout can fit horizontally while still making an essential action unusable.
The next check is whether the page lets someone reach and read the full action without changing the task or losing necessary information. “Make the banner smaller” is only a proposed fix. A recheck must establish what the new version actually does.
R03: A comparison table needs both dimensions
Assume the table's row and column relationships require sideways movement to inspect both service options. The paragraphs before and after it still fit.
W3C's two-dimensional exception is scoped to content that needs it; ordinary surrounding text is not automatically excepted. Individual table cells also need to reflow unless their own content qualifies. Keeping the table's scrolling in its own region is a useful approach, but a page scrollbar alone does not prove failure. Inspect the content that requires it. W3C's exception boundaries
For this example, record which region scrolls, whether every cell can be reached and whether the option and row remain understandable together. Do not “fix” the table by hiding one option or its exclusions. Keyboard operation of that region needs its own check; seeing a scrollbar does not establish it.
R04: A route disappears at the narrow width
Assume the desktop page has a “Read service details” link, but the narrow layout removes it without providing an equivalent route. The visitor can still see the enquiry button, yet cannot revisit the limitation that informs the choice.
Record the missing route and why the task needs it. A compact menu can be an alternative if the route is present and usable there. Do not decide from a screenshot alone that moved content has been lost. Open the relevant navigation when safe and check where it leads.
Write one issue another person can repeat
For R02, a useful fictional handoff is:
Version A, enquiry section, V04. Start at the recorded 1280 CSS-pixel content viewport and use browser page zoom at 400%. Scroll to the enquiry action. In this assumed case, the fixed invitation banner continues to cover the action. Expected: the full label and control can be reached and used. Actual execution: NOT RUN.
In a real check, replace the assumed symptom with your observation and include the resulting viewport measurement, browser/version, exact URL, starting state and evidence reference. If you needed to zoom back out to recover, record that step.
Separate the symptom from its cause. The implementer may need to inspect positioning, wrapping or container behavior. Do not suppress a scrollbar or disable zoom merely to make a screenshot look tidy; check whether the intended content and task remain available.
Recheck the changed version and preserve the limits
Use NOT RUN, BLOCKED, OBSERVED AS EXPECTED or ISSUE OBSERVED for each configuration and case. Record the changed page version and repeat the original steps. A wider desktop result cannot close an issue found only at the narrow configuration.
Use a real observation to close the specific issue. Keep untested states visible. A screenshot supports what is visible in that frame; a successful action needs an interaction check. Neither establishes a saved enquiry, delivered message or booking.
This is a bounded layout review, not an accessibility certification or a complete conformance evaluation. Other pages, keyboard behavior, assistive technology and additional requirements need their own appropriate checks.
Download the narrow-width and zoom worksheet. Pick one page version, list the task's required content and prepare the first configuration record. Give the builder the exact obstacle and the evidence needed to close it.