Responsive Web Design Checklist

Quick answer: begin with a fluid single-column layout, add breakpoints only when content needs them, and test from 320 CSS pixels through wide desktop screens. Include keyboard navigation, 200% zoom, landscape orientation, real touch input and slow-network performance—not only visual resizing.

Responsive design means the same content and functionality remain usable across different space, input and user settings.

Document the test matrix

Use representative environments rather than dozens of near-identical devices:

• narrow mobile viewport around 320 CSS pixels;
• common modern phone widths;
• phone landscape;
• tablet portrait and landscape;
• laptop viewport;
• wide desktop;
• 200% browser zoom;
• increased default text size;
• keyboard-only navigation;
• throttled mobile network;
• at least one real iOS and Android browser when possible.

Test content extremes: longest title, empty state, validation errors, wide table, large image and translated label.

1. Verify the viewport

Include:

<meta name="viewport" content="width=device-width, initial-scale=1">

Do not disable user scaling. Zoom is an accessibility feature.

2. Start with fluid layout primitives

Prefer Grid, Flexbox, percentages, minmax(), intrinsic sizing and bounded clamp() values over fixed page widths. Set a readable maximum content width while allowing the shell to shrink.

MDN’s responsive design guide explains how flexible layouts, media queries, responsive media and typography work together.

Add a breakpoint when a navigation bar wraps badly or a content column becomes unreadable—not because a framework labels a width “tablet.”

3. Test reflow at 320 CSS pixels

WCAG 2.2 Reflow expects typical vertically scrolling content to work at a width equivalent to 320 CSS pixels without requiring two-dimensional scrolling. The official Reflow guidance explains exceptions for content that genuinely needs two-dimensional layout.

Look for:

• fixed-width cards;
• code blocks escaping containers;
• long URLs and filenames;
• tables;
• absolutely positioned labels;
• sticky elements covering content.

Allow code and necessary data tables to scroll inside their own labeled region instead of making the whole page horizontally scroll.

4. Check typography and zoom

Use relative units and adequate line height. Headings should wrap without overlapping controls, and body text should not span the full width of a large monitor.

At 200% zoom:

• navigation remains reachable;
• no text is clipped by fixed heights;
• dialogs remain inside the viewport;
• buttons accommodate longer labels;
• sticky headers do not consume most of the screen.

Use the website font guide to control font loading and fallback shifts.

5. Test navigation

The mobile menu must work with touch and keyboard. Verify:

• the toggle has an accessible name and expanded state;
• focus moves predictably;
• dropdowns do not require hover;
• Escape closes overlays where expected;
• focus is not trapped or lost;
• the current page remains identifiable;
• essential links are not removed on mobile.

Do not hide important navigation solely to make a header look clean.

6. Make images and media responsive

Prevent overflow with intrinsic dimensions and responsive sizing:

img,
video {
    max-width: 100%;
    height: auto;
}

Set HTML width and height to reserve aspect ratio. Use srcset and sizes when different resolutions materially reduce transfer size. Crop with intent; do not cut off product details or text inside informative images.

Give informative images descriptive alt text and decorative images empty alt text.

7. Check forms with the mobile keyboard

Use correct input types and autocomplete tokens. Test with the on-screen keyboard visible.

Confirm:

• labels remain visible;
• errors appear near the relevant field and in text;
• focus is not hidden behind a sticky footer;
• inputs do not trigger unwanted zoom because text is too small;
• date, phone and payment fields accept expected formats;
• submission cannot be triggered twice accidentally.

8. Handle tables and dense data

Prioritize columns, allow a contained horizontal scroll, or transform data into labeled rows when semantics remain clear. Do not simply shrink text until the table fits.

Keep headers associated with cells and provide a visible cue that horizontal scrolling is available.

9. Test touch and pointer interaction

Controls need sufficient size and spacing. Hover effects cannot be the only way to reveal required actions. Test carousels, drag controls and tooltips without a mouse.

Maintain visible keyboard focus even when the pointer design uses subtle hover states.

10. Test orientation and safe areas

Unless a specific function requires one orientation, content should work in portrait and landscape. Check fixed bars around notches and mobile browser controls, and avoid hard-coded viewport heights that hide content when browser chrome changes.

11. Measure performance per breakpoint

Responsive CSS does not make oversized assets cheap. A hidden desktop hero may still download on mobile.

Measure:

• largest image transfer;
• font files and weights;
• render-blocking CSS;
• JavaScript execution;
• layout shifts;
• interaction latency;
• server response time.

Use production-like caching and a cold mobile connection. Optimize the actual Largest Contentful Paint element for each layout.

12. Run the final content checks

For every key template, test:

1. header and footer;
2. long and short pages;
3. search and empty results;
4. 404 and error states;
5. forms and validation;
6. authentication or checkout;
7. cookie and consent controls;
8. embedded media;
9. print output if relevant;
10. reduced-motion preference.

Record failures by component and content condition, not only device name. A durable fix belongs in the shared component system so the next page does not recreate the same bug.