The 320px Fix That Fails: What Real Clients Taught Me About Reflow

The 320px Trap

Everyone says: "Just make it work at 320px and you're done." That advice has been floating around since the first iPhone. It's lazy. I learned the hard way when a client's site passed my 320px checks but broke at 400% zoom. Text vanished. Buttons shrank. Users got frustrated. The 320px test isn't a trend—it's a baseline. If you're only checking that, you're missing the real problem: the layout collapses when someone zooms in, especially at 400%.

What a Real Project Taught Me

Last year, a local bakery came to me with a fixed-width site from 2010. Mobile users couldn't read the menu or tap the order button. The owner had heard about "responsive design" but didn't know what it meant. I had to rebuild it properly, not just for today's phones but for whatever comes next. That project forced me to rethink my approach to reflow.

Stop Obsessing Over Breakpoints—Think Fluidity

Forget "mobile vs desktop." That's the wrong mental model. Responsive design isn't a set of fixed breakpoints; it's about fluid grids, flexible images, and media queries that react to content (MDN). Use percentages, fr, rem, and vw instead of pixels. For images, a simple img { max-width: 100%; height: auto; } prevents overflow. For typography, don't rely on viewport units alone—they break zoom. I now use something like font-size: calc(1.5rem + 4vw) to balance scaling with accessibility (MDN).

Breakpoints? Add them where the content demands, not at arbitrary sizes. Common values like 375px, 768px, 1024px, 1440px are decent starting points, but your content will tell you where to break (MDN). The goal is to avoid horizontal scrolling and content loss, not to hit a magic number.

The Reflow Test Isn't Just 320px

Reflow is a WCAG 2.1 Level AA requirement (SC 1.4.10). Content must be presented without loss of information and without two-dimensional scrolling at a width equivalent to 320 CSS pixels for vertical content, or 256 CSS pixels for horizontal content. That's the same as a 1280x1024 viewport at 400% zoom (W3C). So if you're only testing at 320px, you're missing the zoom scenario. When a user zooms to 400%, your site should still reflow properly—no horizontal scrolling, no cut-off text, no hidden content.

Here's a real example: A nav bar with five links. At 320px, it might fit if you shrink the text, but at 400% zoom (which is effectively a 320px viewport), that nav will overflow. The fix? Use a flex container with flex-wrap, or switch to a vertical layout at narrow widths. Also, text must resize up to 200% without loss of content (W3C). That means no fixed font sizes below 16px, and a line height of at least 1.5.

Touch Targets: 44x44 vs 24x24—What I Actually Do

Here's the tricky part. WCAG 2.2 SC 2.5.8 Target Size (Minimum, Level AA) requires pointer targets to be at least 24x24 CSS pixels, with exceptions (W3C). But Apple's guidelines recommend 44x44 points (Apple), and Android suggests 48x48 dp (Android). So which do you follow?

The blunt answer: follow the stricter one for mobile. 24x24 is a bare minimum that will frustrate users. 44x44 is better for thumbs. But you can't just increase the size of every link—you need to consider spacing too. If you have a row of links, add enough margin so the touch areas don't overlap. A common mistake is making a link look small but having a larger hit area via padding. That's fine, but the visual size and touch target should be consistent.

Contrast and Color: The Silent Killers

Let's talk contrast. The WebAIM Million study of the top 1,000,000 home pages found that 95.9% had WCAG 2 failures, and low-contrast text was the most common issue, present on 83.9% of pages (WebAIM). That's staggering. And it's not just about looks—it's about usability. WCAG 2.1 AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (WCAG). For UI components like buttons and icons, you need at least 3:1 against adjacent colors (WCAG).

Color is another trap. About 1 in 12 men have color vision deficiency (NEI), so you can't rely on color alone to convey meaning. Pair color with labels, icons, or patterns. And every image needs meaningful alt text—empty alt for decorative images (W3C). This isn't just about accessibility; it's about usability. If a user can't distinguish a button from a background, they're going to miss it.

Performance and Core Web Vitals: The Speed Factor

You can have the most accessible site in the world, but if it loads slowly, users will leave. Core Web Vitals are three metrics: LCP (loading), INP (interactivity), and CLS (visual stability). A good LCP is 2.5 seconds or less, INP should be 200 milliseconds or less, and CLS should be 0.1 or less (web.dev). These aren't just nice-to-haves; they're ranking factors and user experience indicators.

One of the easiest ways to improve CLS is to set width and height attributes on images so they reserve space before loading (MDN). Use loading="lazy" for off-screen images to speed up initial load (MDN). And for responsive images, use srcset and sizes to let the browser pick the right resolution, or use picture for art direction (MDN).

Here's a comparison table to help you decide what to prioritize:

The Keyboard and Focus Trap

Finally, don't forget keyboard accessibility. WCAG 2.1 SC 2.1.1 requires that all functionality be operable via a keyboard (W3C). That means your custom dropdowns, modals, and carousels need to be fully navigable with Tab, Enter, and Escape. And you need a visible focus indicator—WCAG 2.1 SC 2.4.7 (W3C). Plus, in WCAG 2.2, SC 2.4.11 requires that focus isn't obscured by author-created content (W3C). So, if you have a sticky header, make sure it doesn't cover the focused element.

Let's say you have a modal dialog. When the user tabs into it, focus should move into the modal and not be hidden behind the backdrop. And when they close it, focus should return to the triggering element. That's not just a nice-to-have; it's a requirement.

The Takeaway

Here's the bottom line: The 320px reflow test is just the starting line. To build a site that truly works, you need to combine fluid grids, proper breakpoints, accessible contrast, touch targets that meet at least 44px, and performance that hits Core Web Vitals. This isn't about ticking boxes—it's about creating a better experience for every user, regardless of their device or ability. Start with a mobile-first approach, test at 400% zoom, and don't stop until your site passes the reflow test without a single horizontal scrollbar. Your users—and your client—will thank you.

Sources

• MDN Web Docs - https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/CSS_layout/Responsive_Design
• WCAG 2.1 (AA) - https://www.w3.org/WAI/WCAG21/quickref/
• 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
• W3C WCAG 2.2 Understanding Target Size (Minimum) - https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html
• WebAIM Million - https://webaim.org/projects/million/
• web.dev (Web Vitals) - https://web.dev/articles/vitals