Why Your Tutorial Should Start with a 320px-Wide Disaster

Everyone preaches mobile-first, but most of us are secretly designing on a 1440px canvas and then shrinking it until it only looks slightly broken. That's backwards. The real test of a responsive layout isn't the beautiful wide screen; it's the 320px-wide disaster where text has to reflow into one column, touch targets must survive fat thumbs, and the design still has to pass WCAG 2.1 AA. We've been there, and we're done pretending that mobile-first is just an aesthetic preference. It's an accessibility requirement with teeth.

Why 320px Is Your New Breakpoint

We used to think breakpoints were about device sizes: 375px for phones, 768px for tablets, 1024px for laptops. But that's a trap. The WCAG 2.1 Reflow criterion (Level AA) demands that content be presentable without loss of information or requiring two-dimensional scrolling at a width equivalent to 320 CSS pixels for vertical content. That's not a suggestion; it's a compliance bar. And here's the kicker: you can't meet that by adding a breakpoint at 320px. You have to design the layout to work fluidly from 320px upward, using relative units, flexible grids, and media queries only when the content actually demands them. The viewport meta tag with width=device-width is your starting gun, but the race is won in your CSS.

Imagine you're a developer at a state agency that must comply with the DOJ's final ADA Title II rule. By April 24, 2026, if you serve a population over 50,000, your public-facing web content must meet WCAG 2.1 AA. That's not hypothetical. And if you're in the EU, the European Accessibility Act applies to products and services after June 28, 2025. The days of treating mobile as an afterthought are legally over. So let's walk through a realistic scenario: you're redesigning a small business's booking site, and you need it to work on a phone held in one hand, a laptop, and everything in between. Here's how the facts apply.

Start with the Content, Not the Canvas

Before you write a single media query, strip the layout down to its semantic HTML skeleton. Use header, nav, main, section, article, and footer so screen readers can navigate regions programmatically. A section should begin with a heading, an article encloses self-contained content, and an aside holds tangential info. This isn't just good practice; WCAG 2.1 Info and Relationships (Level A) requires that structure be conveyed in code, not just visually. When you do that, the content has a natural order that works at any width.

In our booking site, the main content is a form: name, date, time, and a submit button. That form is the core. So we build the HTML first, with labels associated properly, and then we style it. We don't start with a 12-column grid. We start with a single column that stretches to fill the viewport. Then we add container queries to let components adapt to their own space, not just the viewport. Container queries are widely supported since February 2023, and they let a card component decide whether to show a side-by-side layout or stack vertically based on the width of its container. That's powerful for reusable components.

Fluid Type and Images That Don't Break

Typography is where most responsive designs fail. You can't use viewport units alone for font sizes because they prevent zooming. Instead, use clamp(): font-size: clamp(1rem, 2.5vw, 2rem) scales fluidly but respects a minimum and maximum. That way, at 320px, text is still readable, and at 1440px it doesn't balloon. Also, set a base font size of at least 16px, a line height around 1.5, and a line length of roughly 45–75 characters for readability. Those aren't optional; they're WCAG AA recommendations for readability.

For images, the rule is simple: set width and height attributes so the browser reserves space before the image loads, preventing layout shift. Use max-width: 100%; height: auto; to keep them inside their container. If you're serving modern formats, AVIF is about 50% smaller than JPEG, and WebP is 25–35% smaller, but you need fallbacks via the picture element. And use loading="lazy" for off-screen images to speed up initial load. But don't lazy-load the hero image—that's your LCP element.

Touch Targets and the Thumb Zone

Now let's talk about the button. The submit button on our booking form is tiny on a phone if you don't size it right. WCAG 2.2 Target Size (Minimum) requires pointer targets to be at least 24 by 24 CSS pixels, but that's a bare minimum. Apple recommends 44 by 44 points, and Android suggests 48 by 48 dp. For usability, we aim for at least 44px on mobile. That means padding, not just font size. In our CSS, we set a padding of at least 12px vertical and 16px horizontal, giving us a comfortable tap area. And we ensure there's enough spacing between targets so users don't accidentally tap the wrong field.

Dark Mode Without Breaking Contrast

Many of us love dark mode, but it's a trap for contrast. About 1 in 12 men have color vision deficiency, so you can't rely on color alone. WCAG 2.1 AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. In dark mode, it's easy to use colors that look fine but fail contrast checks. A common pattern is to build a light theme by default and then override colors inside a prefers-color-scheme: dark media query. That honors the user's system preference. But you must test your dark palette with a contrast checker. We've seen many sites where the dark mode has gray text on a dark background that's illegible.

Performance and the 320px Reality

Finally, test performance on a slow 3G connection at 320px width. Core Web Vitals are the user experience metrics Google uses: LCP should be under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1. On a small screen, the LCP element might be an image that loads lazily, causing a layout shift. So set dimensions on all images, and use font-display: swap to avoid invisible text. But be careful: font-display: swap can cause a flash of unstyled text, which is fine for performance but can be a bit jarring. We accept that trade-off for faster perceived load.

What I'd actually do

Here's my concrete recommendation: when you start a new responsive project, open your browser's dev tools and set the viewport to 320px wide. Design the entire experience there first—content, navigation, forms, images. Then drag the viewport wider and only add complexity when the content starts to look stretched or unusable. Don't design for a specific device; design for the content's natural breakpoints. And run an automated accessibility check against WCAG 2.1 AA before you even think about custom styling. That's how you avoid the 95.9% of home pages that fail WCAG, as found by WebAIM's Million study. We owe our users better than that.

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
• web.dev (Web Vitals) - https://web.dev/articles/vitals
• WebAIM Million - https://webaim.org/projects/million/
• Apple Human Interface Guidelines - https://developer.apple.com/design/human-interface-guidelines/accessibility
• MDN Web Docs (@container) - https://developer.mozilla.org/en-US/docs/Web/CSS/@container