Myth: "My site is responsive because it has a mobile menu."
That's like saying your car is safe because it has a steering wheel. A mobile menu is a nice touch, but it doesn't mean your layout can survive a 320px viewport without horizontal scrolling. WCAG 2.1 SC 1.4.10 (Reflow, Level AA) requires that content be presented without loss of information and without requiring scrolling in two dimensions at a width equivalent to 320 CSS pixels (W3C WCAG 2.1 Understanding Reflow). That's not a suggestion; it's a legal and usability benchmark. If your site fails that, you're not responsive—you're just small.
Why is 320px the magic number?
Because that's roughly the width of an older iPhone SE or a narrow Android device. It's also the width that WCAG picked to simulate a 400% zoom on a 1280px desktop viewport (W3C WCAG 2.1 Understanding Reflow). The point isn't to make everything look pretty at 320px; it's to ensure that when someone zooms in or uses a narrow screen, they don't have to pan left and right to read a sentence. If you've ever seen a horizontal scrollbar on your phone, you know the pain. Your users feel it too.
"But my breakpoints are at 375px and 768px—isn't that enough?"
Breakpoints are a means, not an end. The MDN Web Docs advise adding breakpoints when content demands them, not at arbitrary device sizes (MDN Web Docs). If your design only kicks in at 375px, then at 320px you're likely in a broken, unscaled state. The fix is to test at 320px specifically. Open your dev tools, set the viewport to 320px, and see what breaks. If you see horizontal scrolling, your grid is too rigid or your minimum content width is too wide. Use fluid grids with relative units like percentages or fr, and let flexbox or CSS Grid wrap naturally (MDN Web Docs). A simple img { max-width: 100%; } can save you from overflow disasters (MDN Web Docs).
Do I really need to support 320px? Isn't that obsolete?
No, and here's why: WCAG's reflow requirement isn't just about old phones. It's about zoom. When a user zooms to 400% on a desktop, the effective viewport becomes 320px wide (W3C WCAG 2.1 Understanding Reflow). So even if your analytics show zero 320px devices, you still have users who zoom. And WebAIM's Million study found that low-contrast text is the most common accessibility error, present on 83.9% of home pages (WebAIM Million). That's not directly about reflow, but it shows how many sites ignore basic accessibility. Don't be one of them. Build for 320px, and you're building for everyone.
Okay, but how do I actually pass the 320px reflow test?
Here's a blunt checklist: First, set your viewport meta tag correctly: <meta name="viewport" content="width=device-width, initial-scale=1.0"> (MDN Web Docs). Then, test at 320px. Look for horizontal scrollbars. If you find them, inspect the offending element. Often it's a fixed-width container, a long unbreakable string, or a table. Use overflow-wrap: break-word; for long URLs, and consider using min-width: 0 on flex children to allow them to shrink. For tables, you might need to switch to a card layout on narrow screens. And remember: you don't need to support 320px in every layout perfectly—just ensure that content is accessible without two-dimensional scrolling. But the moment you start testing, you'll find that your design might need a few tweaks.
What about text resizing? Is that the same as reflow?
Not quite. WCAG 2.1 SC 1.4.4 (Resize Text, Level AA) says text must be resizable up to 200% without loss of content or functionality (W3C WCAG 2.1 Understanding Resize Text). That's separate from reflow, which is about layout at a fixed viewport. However, if you use viewport units for font sizing alone, you break zoom—because the text doesn't scale with the browser's zoom. MDN recommends combining viewport units with fixed units, like font-size: calc(1.5rem + 4vw) (MDN Web Docs). Or use clamp() to set a fluid range with safe minimum and maximum sizes (MDN Web Docs). That way, text scales smoothly, but users can still zoom.
Is there a difference between 320px and 400% zoom? Do I need to test both?
They're equivalent in terms of effective viewport width: 320px is the same as 1280px at 400% zoom (W3C WCAG 2.1 Understanding Reflow). But testing both can reveal different issues. At 320px, you're seeing the actual mobile layout. At 400% zoom on desktop, you're seeing how the browser handles zoom—sometimes it triggers the mobile layout, sometimes it doesn't. So test both, but the 320px viewport is easier to simulate. Use that as your baseline.
Let me give you a concrete example. Say you have a card grid with three columns on desktop. At 320px, those columns might each be 100px wide, which is too narrow for text. Instead, let the grid collapse to one column by using grid-template-columns: repeat(auto-fit, minmax(250px, 1fr));—that way, the grid automatically wraps to one column on narrow screens. That's a fluid grid, and it's the foundation of responsive design (MDN Web Docs).
Now, here's a comparison of common approaches to handling narrow viewports:
| Approach | Pros | Cons |
|---|---|---|
| Fixed breakpoints (e.g., 375px, 768px) | Simple to implement, predictable | May not cover all sizes, can break at 320px |
| Fluid grids with relative units | Naturally adapts to any width, no breakpoints needed | Requires careful design, may need min/max constraints |
| Hybrid: fluid + breakpoints | Best of both worlds, handles edge cases | More complex, requires testing at multiple sizes |
My recommendation? Go hybrid. Use fluid grids as your baseline, then add breakpoints when content demands it (MDN Web Docs). And always test at 320px—it's the litmus test for true responsiveness.
One more thing: don't forget images. Set width and height attributes on your img tags to reserve space and prevent layout shift (MDN Web Docs). Use srcset and sizes to serve the right resolution, and consider loading="lazy" for off-screen images to improve performance (MDN Web Docs). And if you're using picture for art direction, always include a fallback img with src and alt (MDN Web Docs).
Finally, remember that accessibility is not a trend. The DOJ's ADA Title II rule now requires state and local governments to meet WCAG 2.1 AA (Federal Register (DOJ ADA Title II rule)), and Section 508 already requires federal agencies to follow WCAG (Section 508 Standards (U.S. Access Board)). But even if you're not in the public sector, your users expect a site that doesn't break on their phone. The 320px reflow test is your friend. Run it, fix the issues, and you'll have a site that works for everyone.
Takeaway: Stop guessing. Set your viewport, test at 320px, fix horizontal scrolling, and use fluid layouts. That's not just good practice—it's the law for many, and it's the right thing for all. Your users will thank you, and so will your Google rankings.
Sources
- MDN Web Docs - https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/CSS_layout/Responsive_Design
- W3C WCAG 2.1 Understanding Reflow - https://www.w3.org/WAI/WCAG21/Understanding/reflow.html
- W3C WCAG 2.1 Understanding Resize Text - https://www.w3.org/WAI/WCAG21/Understanding/resize-text.html
- WebAIM Million - https://webaim.org/projects/million/
- Federal Register (DOJ ADA Title II rule) - https://www.federalregister.gov/documents/2024/04/24/2024-07758/nondiscrimination-on-the-basis-of-disability-in-accessible-web-information-and-technology
- Section 508 Standards (U.S. Access Board) - https://www.section508.gov/manage/laws-and-policies/
Comments (0)
Please sign in to post a comment.
Don't have an account? Create one
No comments yet. Be the first to comment!