Practical guide · AI & interfaces
5 min read
Updated
Make a page work on narrow screens
Adapt a page to phones and browser zoom while keeping its content and actions available.
Direct answer
A responsive page rearranges its content when space changes. Start with a usable single column, then add columns where the content benefits. Keep the same task achievable at narrow widths; shrinking a desktop screenshot is not a responsive layout.
01
1. Start from the task, then choose the layout
For a course page, write the reading order first: course title, explanation, price, enrollment action, then supporting details. Sketch that order as one column before arranging the price alongside the explanation on a wider screen. This is an original planning exercise, not a prescribed layout for every product.
Use responsive layout when the same information must remain usable across window sizes. A different mobile application may solve different tasks, but hiding the price or enrollment action simply to make this page fit changes its usefulness. Decide explicitly where each displaced element goes.
02
2. Let real content reveal the breakpoint
Use a viewport setting that follows the device width and allows zoom. Prefer flexible dimensions over a fixed desktop canvas. Choose a breakpoint when the actual content becomes cramped, rather than because a named phone model has a particular width.
In the course example, test the longest French title, a two-line price description and an enrollment label that wraps. Narrow the window slowly. When the two columns stop supporting readable content, stack the price panel after the explanation. Record that transition and test just above and below it; a screenshot at only two endpoints can miss a broken middle width.
03
3. Check the whole enrollment journey
Open a course with a long title, expand its prerequisites, follow the enrollment action, then return. Repeat with the price panel stacked. Confirm that the action keeps its label and destination, prerequisites remain reachable, and focus follows a meaningful sequence. Keep expected and observed results separately.
Include a slow-loading illustration and unusually long text in this exercise. Fit media inside its container and retain useful proportions. If a string still forces overflow, investigate that element instead of clipping the entire page. Clipping can conceal the symptom while leaving an action unreachable.
- The expanded prerequisites remain reachable after the price panel moves.
- The enrollment label and destination stay consistent across layouts.
- Returning from enrollment restores a usable page rather than a clipped panel.
04
4. Distinguish reflow from magnification
WCAG 2.2 Reflow, level AA, concerns presentation at 320 CSS pixels wide for vertically scrolling content without lost information or functionality or a need to scroll in both directions. A 1280 CSS pixel viewport at 400% browser zoom reaches that width. Pinch magnification alone does not establish this.
Content whose meaning requires two dimensions, such as a data table, can have an exception. It does not exempt the surrounding heading, explanation or controls. Contain table scrolling and document the exception.
05
5. Keep layout evidence separate from accessibility claims
Test the course page at the measured narrow viewport and through an intermediate width, then complete enrollment navigation with the keyboard. Recheck any fixed header or bottom action that can cover content. Capture the build, viewport, zoom, browser and failing step when something becomes unreachable.
This guide describes a layout process; it does not modify your website or certify accessibility. Responsive rendering alone does not establish correct labels, contrast, focus behavior or performance. A simulated phone viewport also does not prove usability on a physical phone. Use the linked verification guide for the wider interface checks.
Keep this
Verify the result
- 01The long EN and FR versions keep the course explanation, price and action available.
- 02The layout works around each breakpoint, not only at two screenshot sizes.
- 03The measured 320 CSS pixel check records any justified exception.
- 04Keyboard navigation reaches the same intended enrollment destination.
- 05Observed results name the tested build, browser and viewport.
- 06Fixed headers and bottom actions leave the focused control visible during the journey.
Primary sources
Technical claims in this guide connect to first-party specifications and documentation.
- Responsive web design basics (opens in a new tab)Google web.dev · Primary guidance for the relevant layout checks; the working example is original and does not certify conformance.
- Understanding SC 1.4.10: Reflow (opens in a new tab)W3C WAI · Primary guidance for the relevant layout checks; the working example is original and does not certify conformance.
Continue
Related guides and tools
Understand → Recognize → Choose → Compare
Pack for your agent
Pre-written instruction by SkillCodex — your request is neither sent nor used to adapt this text; no content is generated, and copying executes nothing.
Implement correctly
Apply “Make a page work on narrow screens” step by step
# Apply the “Make a page work on narrow screens” guide in your agent ## Objective A responsive page rearranges its content when space changes. Start with a usable single column, then add columns where the content benefits. Keep the same task achievable at narrow widths; shrinking a desktop screenshot is not a responsive layout. ## Prerequisites - Inspect the repository, documentation, and existing conventions. - Confirm the need matches the guide scope: Adapt a page to phones and browser zoom while keeping its content and actions available. - Preserve the correct decisions already in place. ## Guide steps - 1. 1. Start from the task, then choose the layout — For a course page, write the reading order first: course title, explanation, price, enrollment action, then supporting details. Sketch that order as one column before arranging the price alongside the explanation on a wider screen. This is an original planning exercise, not a prescribed layout for every product. - 2. 2. Let real content reveal the breakpoint — Use a viewport setting that follows the device width and allows zoom. Prefer flexible dimensions over a fixed desktop canvas. Choose a breakpoint when the actual content becomes cramped, rather than because a named phone model has a particular width. - 3. 3. Check the whole enrollment journey — Open a course with a long title, expand its prerequisites, follow the enrollment action, then return. Repeat with the price panel stacked. Confirm that the action keeps its label and destination, prerequisites remain reachable, and focus follows a meaningful sequence. Keep expected and observed results separately. - 4. 4. Distinguish reflow from magnification — WCAG 2.2 Reflow, level AA, concerns presentation at 320 CSS pixels wide for vertically scrolling content without lost information or functionality or a need to scroll in both directions. A 1280 CSS pixel viewport at 400% browser zoom reaches that width. Pinch magnification alone does not establish this. - 5. 5. Keep layout evidence separate from accessibility claims — Test the course page at the measured narrow viewport and through an intermediate width, then complete enrollment navigation with the keyboard. Recheck any fixed header or bottom action that can cover content. Capture the build, viewport, zoom, browser and failing step when something becomes unreachable. ## Acceptance criteria — Verify the result - The long EN and FR versions keep the course explanation, price and action available. - The layout works around each breakpoint, not only at two screenshot sizes. - The measured 320 CSS pixel check records any justified exception. - Keyboard navigation reaches the same intended enrollment destination. - Observed results name the tested build, browser and viewport. - Fixed headers and bottom actions leave the focused control visible during the journey. ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
- Requires · The real project context: repository, documentation, and existing constraints
Why it works
- The steps come from a published, sourced guide, not improvisation.
- The checklist turns advice into verifiable criteria.
- The declared scope keeps the guide within its evidence.
Try next
Anchor the guide in the project
# Anchor the guide in the project ## Objective Turn the applied steps into durable repository conventions. ## Checks - Link each decision made to the guide step that justifies it. - Add the checklist to the relevant reviews. - Record out-of-scope cases for the neighboring guides. ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
sha256:7c743cde722a275f362074973375583bd6156a4edc6157878342fadb572861b2
Diagnose a problem
Diagnose a “Make a page work on narrow screens” guide gap
# Diagnose a failed application of the “Make a page work on narrow screens” guide ## Observed symptom [DESCRIBE THE SYMPTOM HERE] ## Observable checks - Replay the steps in order and note the first one that diverges: - 1. 1. Start from the task, then choose the layout — For a course page, write the reading order first: course title, explanation, price, enrollment action, then supporting details. Sketch that order as one column before arranging the price alongside the explanation on a wider screen. This is an original planning exercise, not a prescribed layout for every product. - 2. 2. Let real content reveal the breakpoint — Use a viewport setting that follows the device width and allows zoom. Prefer flexible dimensions over a fixed desktop canvas. Choose a breakpoint when the actual content becomes cramped, rather than because a named phone model has a particular width. - 3. 3. Check the whole enrollment journey — Open a course with a long title, expand its prerequisites, follow the enrollment action, then return. Repeat with the price panel stacked. Confirm that the action keeps its label and destination, prerequisites remain reachable, and focus follows a meaningful sequence. Keep expected and observed results separately. - 4. 4. Distinguish reflow from magnification — WCAG 2.2 Reflow, level AA, concerns presentation at 320 CSS pixels wide for vertically scrolling content without lost information or functionality or a need to scroll in both directions. A 1280 CSS pixel viewport at 400% browser zoom reaches that width. Pinch magnification alone does not establish this. - 5. 5. Keep layout evidence separate from accessibility claims — Test the course page at the measured narrow viewport and through an intermediate width, then complete enrollment navigation with the keyboard. Recheck any fixed header or bottom action that can cover content. Capture the build, viewport, zoom, browser and failing step when something becomes unreachable. ## Possible causes - A step was skipped or executed out of order. - The actual need falls outside the guide scope. - A checklist criterion was never verified. ## Bounded fixes - Redo only the diverging step and what depends on it. - Document the gap if the guide scope does not cover the need. ## Final verification — Verify the result - The long EN and FR versions keep the course explanation, price and action available. - The layout works around each breakpoint, not only at two screenshot sizes. - The measured 320 CSS pixel check records any justified exception. - Keyboard navigation reaches the same intended enrollment destination. - Observed results name the tested build, browser and viewport. - Fixed headers and bottom actions leave the focused control visible during the journey. ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
- Requires · The real project context: repository, documentation, and existing constraints
Why it works
- The diagnosis replays ordered steps instead of searching at random.
- Fixes stay bounded to the first real divergence.
- The checklist serves as a reproducible final verification.
Try next
Prevent the next drift
# Prevent the next drift ## Objective Turn the first diverging step into an explicit project check. ## Checks - Add a focused check on the step that diverged. - Verify the checklist on a second real case. - Document the scope limit you hit. ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
sha256:6c69f9557b6f91a699414dbd06c5a6dcc5f6ffb9e1397f6937138c45acb1de33
Pack digest: sha256:55ed138168d4ea957401cd63e6a6b6b551c3d19a53bb7ace2e91a76ae7feb04e