1. Choose the page’s job before choosing its layout
Begin with pages that carry a customer or business task: service pages, product pages, lead forms, booking, account entry, cart, and help. Write one completion statement for each, such as: “A first-time visitor can understand this service, see relevant proof, and request a call.” If the page has more than one job, decide which appears first.
List its content as essential, supporting, or optional. Essential does not mean brief; a visitor may need price context, eligibility, delivery detail, or comparison information. Give that material a clear route on the narrow layout. Google advises equivalent primary content on mobile and desktop, while allowing a different presentation such as tabs or accordions.
At a narrow width, a colleague should be able to say what the page offers, who it helps, and the next meaningful action.
2. Make the narrow baseline complete
Start with a working single-column path rather than shrinking a desktop layout. Use flexible containers, let text wrap, and include a viewport setting that lets the browser size the layout to the device width. Do not prevent zooming. Check that menus, notices, images, embeds, and form errors stay inside the viewport; unintended page-level horizontal scrolling is normally a defect.
Use 320 CSS pixels as a demanding reflow check for ordinary reading and task content. WCAG 2.2 describes presenting vertical content at that width without loss of information or functionality or two-dimensional scrolling. A map, chart, or data table can need its own scroll region, but that does not justify making the surrounding page scroll sideways.
Fit images to their container and provide dimensions so the browser can reserve space before they load.
3. Add enhancements without making the base path fragile
Progressive enhancement means that essential content and functionality work as a baseline, while capable browsers and larger screens receive extras. The address, product details, form labels, price explanation, and submit path should not depend on animation, hover, or a late script. A wider layout can add a comparison panel, persistent navigation, or richer filtering without making the baseline incomplete.
Ask the implementer to add a breakpoint when the content becomes cramped or wasteful, not because a named device appears in a list. A breakpoint is simply where a layout rule changes. Do not use narrow layouts to silently remove help text, policy terms, reviews, metadata, or important structured details.
Show a basic gallery image and description first, then add zoom or swipe controls when their scripts are available.
4. Design controls for touch, clarity, and recovery
Touch ergonomics means designing for hands rather than a precise mouse pointer. Give buttons, checkboxes, close icons, quantity selectors, and form choices enough size and separation to reduce wrong taps. Label icons when their meaning is not obvious. Do not make hover the only way to reveal a price, submenu, explanation, or action.
WCAG 2.2 includes a Level AA target-size criterion of at least 24 by 24 CSS pixels for pointer targets, with stated exceptions including spacing and inline links. Treat that as a minimum reference, not a comfort guarantee. Critical actions deserve clear labels, generous spacing, and a reversible confirmation step. Seek qualified accessibility review for high-risk journeys or formal conformance claims.
Keep labels visible, show usable validation feedback, and retain entered values after an error.
5. Treat media and embeds as part of the visitor journey
Decide whether each image is informative, persuasive, or decorative. An informative image needs an appropriate text alternative and a narrow-layout crop that preserves the necessary detail. Responsive image options let browsers choose a suitable resource instead of making every visitor download the largest desktop asset. Do not let a hero image or video obscure the page purpose and primary action.
Inventory maps, chat, video, payment, scheduling, consent, and review widgets. On a narrow screen, check their loading state, control size, bounded layout, and a practical fallback route. For payment, identity, or regulated data flows, involve qualified security, privacy, and compliance reviewers; visual testing is not a security assessment.
Record each external component, its owner, its business function, and the approved fallback if it is slow or broken.
6. Test task paths before release and plan remediation
Use browser responsive mode early to inspect narrow, medium, and wide widths. Chrome Device Mode can approximate viewport, touch, orientation, network, and CPU conditions, but Chrome documents it as an approximation rather than real-device execution. Complete critical paths on actual phones and relevant browsers when you can.
Test a task, not only a screenshot: cold load, navigation, invalid and valid form submission, orientation change, zoom, and return from a third-party screen. Record the URL, browser or device, task, expected result, owner, and rollback decision. For major template, checkout, CMS, or dependency changes, stage the release and prepare to restore the previous path rather than improvising under pressure.
Approve only after the critical task works, controls are usable, page-level horizontal scroll is absent, and key dependencies have a fallback.