Designing for 320px: Why Reflow Should Be Your First UI/UX Test

Most teams think "mobile-first" means designing at 375px, the width of the latest iPhone. That's wrong. The real baseline for a resilient, accessible interface is 320px — the width at which WCAG 2.1 Level AA requires content to reflow without horizontal scrolling. If your layout survives 320px, it will survive almost anything. If it doesn't, you're shipping a fragile experience that excludes a significant chunk of users.

Let's walk through a realistic scenario: you're a UI/UX designer at a mid-sized e-commerce company, tasked with redesigning the product listing page. The current page works fine on desktop and looks okay on a 375px phone, but you've seen screenshots from users on older Android devices where the filter sidebar causes horizontal scrolling. You decide to rebuild it properly, using reflow as your guiding constraint.

Start with Content, Not Breakpoints

The first step is to stop thinking in terms of fixed device sizes. Breakpoints should be added when content demands them, not at arbitrary widths like 375px or 768px (MDN Web Docs). So instead of designing for iPhone, you define a mobile-first layout at 320px, then add breakpoints only where the layout starts to break.

For the product listing, you begin with a single-column layout: a search bar, a filter toggle button, and a grid of product cards that stacks vertically. You use CSS Grid with grid-template-columns: repeat(auto-fill, minmax(160px, 1fr)) so the cards reflow naturally as the viewport widens. No fixed widths, no horizontal overflow.

But reflow isn't just about grid columns. It's about ensuring no content is lost or requires scrolling in two dimensions at 320px width (or 256px for horizontal content) (W3C WCAG 2.1 Understanding Reflow). That means the filter sidebar can't be a permanent side panel — it has to become a collapsible drawer, toggled by a button, and the product cards must shrink or wrap gracefully.

Typography That Scales Without Breaking

Once the layout skeleton is in place, you tackle typography. A common mistake is using viewport units alone for font sizes, which prevents users from zooming text. Instead, you use a fluid type approach with clamp(), combining a fixed base with a viewport-relative value. For example, font-size: clamp(1rem, 2.5vw, 2rem) gives you a minimum of 16px, a preferred value that scales, and a maximum of 32px (MDN Web Docs).

You also need to ensure text can resize up to 200% without breaking the layout (W3C WCAG 2.1 Understanding Resize Text). At 200% zoom, the effective viewport becomes roughly 640px wide, so your breakpoints must handle that. You test at 320px at 100% and at 640px at 200% — both should look clean.

For body text, you set a minimum of 16px, a line height of 1.5, and a line length of about 60 characters (WCAG 2.1 AA). These are not arbitrary; they're proven readability standards that also help with reflow.

Images, Touch Targets, and the Little Things

Images are often the biggest cause of horizontal overflow. You set img { max-width: 100%; height: auto; } to keep them within their container (MDN Web Docs). You also add explicit width and height attributes to every image so the browser reserves space and prevents layout shifts (MDN Web Docs). For product photos, you use the srcset and sizes attributes to serve appropriately sized images, and you consider the picture element for art direction — different crops for different breakpoints (MDN Web Docs).

Touch targets are another pain point. At 320px, space is precious, but your filter toggle button must be at least 44x44 pixels (WCAG 2.1 AA). Apple recommends 44x44 points (Apple Human Interface Guidelines), and Android pushes for 48x48 dp (Android Developers (accessibility)). You go with 48x48 to satisfy both, and you make sure there's spacing between targets to avoid mis-taps.

Other details:

• Use semantic HTML (header, nav, main, article) so screen readers can navigate the page structure (MDN Web Docs).
• Provide visible focus indicators — a 3:1 contrast ratio against adjacent colors — and ensure focus isn't obscured by sticky headers or modals (WCAG 2.1 AA; W3C WCAG 2.2 Understanding Focus Not Obscured).
• Don't rely on color alone to convey product availability; pair it with a label or icon (WCAG 2.1 AA).

Test at 320px, Then Extend Outward

With the layout built, you test it at 320px using Chrome DevTools. You check for horizontal scroll, overlapping text, and clipped content. You find that the sticky header's search bar is too narrow, so you adjust its padding. You also notice that the filter drawer's close button is only 32px wide — you bump it to 44px.

After fixing those, you add breakpoints at 600px and 900px (MDN Web Docs). At 600px, the product grid goes from one column to two; at 900px, you bring back a sidebar layout using CSS Grid. You also take advantage of container queries for the product card component itself — using @container so the card adapts to its container's width, not the viewport (MDN Web Docs (@container)). This way, the same card works in a tight sidebar or a wide main column.

Finally, you run a quick accessibility audit. You're aiming for WCAG 2.1 AA, which is now a legal requirement for many organizations: the DOJ's ADA Title II rule mandates it for state and local governments (Federal Register), and the European Accessibility Act applies to e-commerce and banking services (EUR-Lex Directive (EU) 2019/882). Even if you're not legally obligated, the WebAIM Million study found that 95.9% of home pages had accessibility errors, with low contrast text being the most common (WebAIM Million). You don't want to be part of that statistic.

The One Thing to Remember

If you take away one thing: start with 320px, not 375px. It's not just about supporting old phones; it's about forcing your design to be flexible, content-first, and accessible. If your layout works at 320px, it will work at 375px, 768px, and beyond. And you'll be a better designer for it.

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
• Apple Human Interface Guidelines - https://developer.apple.com/design/human-interface-guidelines/accessibility
• Android Developers (accessibility) - https://developer.android.com/guide/topics/ui/accessibility/apps
• WebAIM Million - https://webaim.org/projects/million/