Why You Need an Acceptance Checklist
Most layout problems "discovered after launch" were never systematically checked before delivery. A familiar scenario: the design is pixel-perfect at 1440px and development matches the mockup — but real visitors are opening the site on a 375px iPhone or a 1366px Windows laptop. The nav collapses, tables overflow, images distort. None of it surfaces during acceptance, and you only find out through user complaints.
A checklist turns "eyeballing it" into "verifying item by item against a pass condition." The list below is organized by dimension, each item with a judgment standard and a concrete check method you can use directly as a sign-off basis. It works even better alongside the responsive navbar template: make sure the component itself is responsive first, then accept the whole page.
Breakpoint & Viewport Coverage
Testing a single width is not enough. Cover at least five core breakpoints and walk through each one in Chrome DevTools device mode, watching closely for layout jumps between 768px and 1024px.
| Breakpoint | Typical Device | Focus |
|---|---|---|
| 320px | iPhone SE, some Android phones | No text overflow, single column |
| 375px | iPhone 14/15 mainstream | Nav usable, buttons tappable |
| 768px | iPad portrait | Two columns collapse correctly |
| 1024px | iPad landscape, small laptop | Table width, sidebar layout |
| 1440px | Desktop monitor | Max content width, whitespace rhythm |
Navigation & Interaction
- The hamburger menu expands and collapses below 768px, with clear closing feedback;
- All tappable elements have a touch target of at least 44×44px (Apple HIG and WCAG 2.2 recommendation), with at least 8px spacing between adjacent targets;
- Dropdowns open on tap on touchscreens, not only on hover;
- The full nav is reachable with the Tab key and the focus indicator is clearly visible.
Images & Media
- Use srcset/sizes to serve multiple resolutions, so high-DPI screens don't fetch oversized images and low-DPI screens don't waste bandwidth;
- Above-the-fold images load eagerly; below-the-fold images lazy load;
- Reserve width and height for image containers to prevent layout shift (this directly protects the CLS metric);
- Text-based images stay sharp on high-DPI displays with DPR 2 or 3.
Tables & Typography
- On mobile, wrap tables in a horizontally scrollable container instead of compressing them until unreadable;
- Use clamp() for fluid type scaling on small screens, keeping body line-height around 1.5;
- Keep body line length within 60-80 characters to avoid reading fatigue;
- Hide non-critical columns on small screens, or switch to a card layout.
Performance & UX
- Mobile LCP within 2.5s and CLS below 0.1 (Core Web Vitals thresholds) — dig deeper with the Core Web Vitals guide if needed;
- Hover effects don't leave content "stuck" on touch devices;
- Rotating between portrait and landscape doesn't break the layout or introduce an unexpected horizontal scrollbar.
Testing Recommendations
Test with at least three browser engines — Chrome, Safari, and Edge — on real devices or simulators, and archive the screenshots. Also cover iOS Safari and Android Chrome on physical devices: DevTools simulation still differs from real devices in font rendering and viewport behavior. Record pass/fail, screenshots, and notes for every item to produce a traceable acceptance report you can keep on file.
A Workable Acceptance Workflow
To turn the checklist into a workflow, follow four steps. First, after development, walk all five breakpoints in DevTools device mode, mainly checking for broken layouts. Second, spot-check the homepage and 2-3 key subpages on physical devices (at least one iOS Safari and one Android Chrome). Third, record screenshots and issues in a table with severity levels (blocking release / can defer / just a suggestion). Fourth, after fixing, re-run only the affected breakpoints rather than a full retest.
In a team, drop this checklist into the project README or test-case tool and tick it after every iteration, so the "this change is too small to test" mindset never slips in. For sites with heavy mobile traffic, also see mobile-first indexing and image lazy loading for further optimization details.
FAQ
If I tested 375px, do I still need 320px? Yes. The layout logic may be identical, but at 320px the usable space for type, spacing, and touch targets shrinks noticeably — long Chinese titles in particular wrap and overflow more easily at narrower widths.
Is the simulator enough? Not entirely. Simulators don't reflect real network speed or font rendering, so spot-check critical pages on physical devices.
Who should run the checklist? A dual track works best: developer self-check plus a tester's review, so you avoid the blind spots of reviewing your own work.
How do I confirm the layout change didn't break SEO? Layout changes usually don't touch content, but confirm the page title, H1, and structured data weren't accidentally removed during the responsive refit; run Lighthouse before and after and compare LCP and CLS.
Reference: MDN Responsive Design — https://developer.mozilla.org/docs/Learn/CSS/CSS_layout/Responsive_Design ; Google web.dev Learn Responsive Design — https://web.dev/learn/design