Skip Mobile-First: Container Queries and Reflow Are the Real Test

Let's say something that will get us thrown out of the design meetup: mobile-first is a crutch. We've been parroting it for a decade, but it's time to admit that building for the smallest screen first and then adding media queries for larger viewports is no longer the smartest way to build responsive sites. It's not wrong, exactly—it's just incomplete. It tests our layouts against the viewport, not against the content, and it ignores the real constraint: accessibility. The actual benchmark isn't how the site looks on an iPhone SE; it's whether the content survives a 320-pixel-wide viewport at 400 percent zoom without breaking. That's WCAG 1.4.10 Reflow (Level AA), and it's the most challenging, most revealing test we can run (W3C WCAG 2.1 Understanding Reflow). In this tutorial, we're going to compare two approaches to responsive design—the classic viewport-based media query approach and the newer container-query approach—and then make a recommendation that might surprise you.

The two approaches we're comparing

For this head-to-head, we're putting Classic Viewport-first against Container-first. The Classic approach is the one most of us learned: you set a viewport meta tag, use fluid grids with percentages and fr units, and then layer on media queries at roughly 375px, 768px, 1024px, and 1440px breakpoints (MDN Web Docs). The Container-first approach, by contrast, is built around CSS container queries, which let components respond to the size of their container rather than the viewport—so the same card component can adapt whether it sits in a narrow sidebar or a wide content column (MDN Web Docs (@container)). Container queries have been Baseline Widely available since February 2023, so they're no longer a future-tech experiment.

Both approaches can produce a responsive site, but they differ fundamentally in how they handle the relationship between layout and content. Classic media queries treat the viewport as the source of truth; container queries treat the layout as a collection of independent components. That distinction matters when you start thinking about reflow and accessibility.

Reflow: the test that media queries fail

WCAG 2.1 SC 1.4.10 Reflow requires that content be presented without loss of information or functionality and without requiring two-dimensional scrolling at a width equivalent to 320 CSS pixels (for vertical content) or 256 CSS pixels for horizontal content—which is essentially a 1280 by 1024 viewport zoomed to 400 percent (W3C WCAG 2.1 Understanding Reflow). This is a brutal test. If you've built a media-query-based site with fixed breakpoints, you'll find that at 400 percent zoom, the viewport is effectively 320px wide, but your media queries may not activate because they're based on CSS pixels, not zoom level. The browser zooms, and your media queries don't re-fire. The content has to reflow purely via fluid layouts and flexible images.

Here's where the Classic approach often stumbles. If you've used a grid with a fixed number of columns at a certain breakpoint, and you've set the grid to, say, 12 columns with a fixed gap, at 320px the columns may become too narrow, causing text to overflow horizontally. The fix is to ensure that your layout can collapse to a single column when needed—but that's exactly what container queries can do better. With container queries, you can define the component's behavior based on its own width. If the container is 300px wide, the component stacks vertically; if it's 800px, it goes side-by-side. That's a much more natural way to handle reflow because the component is tested in isolation.

Container queries: the new kid that's actually better

Container queries aren't just a gimmick. They solve a real problem that media queries have always had: components are not aware of their own context. A media query can only ask, "How wide is the viewport?" It can't ask, "How wide is my parent container?" So if you have a card that needs to look good in a sidebar (300px wide) and in a main content area (800px wide), you have to write two separate sets of styles, or use a utility class to differentiate them. Container queries let you write the component once, and it adapts to its container. The syntax is straightforward: you declare a container with container-type: inline-size; and then use @container rules inside the component's CSS. You can even use container query length units like cqw (1% of the container's width) and cqi (1% of the container's inline size) to size typography and spacing relative to the container (MDN Web Docs (container queries guide)).

But the real advantage is accessibility. When you design with container queries, you're forced to think about the smallest container the component can live in. That's a much better proxy for reflow than a viewport breakpoint. If a component works at 300px container width, it will work at 320px viewport width, because the viewport is just the container at the page level. Container queries make it easier to meet the reflow requirement because you're continuously testing the component at various sizes, not just at a few viewport breakpoints.

We should also mention that container queries are not a replacement for media queries—they're a complement. You'll still need media queries for whole-page layout changes, like when the sidebar collapses below the main content on a narrow viewport. But the components inside that layout can be container-query-driven. It's a hybrid approach, and that's exactly what we recommend.

The comparison table

Here's how the two approaches stack up on the criteria that matter most to us as working practitioners:

Our recommendation: go container-first, but keep media queries for the whole page

So who is each approach for? Classic Viewport-first is still the right choice if you're working on a small, content-focused site with a simple layout—a personal blog, a brochure site, a landing page. There's no need to over-engineer with container queries when you have one main column and a few components. Container-first is for anyone building a component library, a design system, or a site with complex, reusable patterns—like a dashboard, an e-commerce site, or a marketing site with many card types. If you find yourself writing the same media query over and over for the same component in different contexts, you're a candidate for container queries.

But here's our specific recommendation: adopt a container-first philosophy for all components, but don't throw away media queries. Use media queries for what they're good at—defining the overall page structure (e.g., when the sidebar stacks below the main content). Then, inside each component, use container queries to handle that component's internal layout. This hybrid approach gives you the best of both worlds: the simplicity of viewport-based design for the page skeleton, and the flexibility of container-based design for the building blocks. And it makes meeting WCAG 2.1 Reflow much easier, because you're designing components to survive at 320px width from the start.

To see this in practice, let's imagine a typical product card. In a Classic approach, you'd write a media query at 480px to switch the card from vertical to horizontal layout. But the same card might appear in a 300px sidebar and a 700px main column. You'd need to duplicate the card styles or add a modifier class. With container queries, you write the card styles once, with a @container rule that switches to horizontal when the container is wider than 400px. The card now adapts to its context naturally. And if you test that card in a 300px container and it works, you've just proven it meets reflow at 320px viewport width (since the card's container will never be wider than the viewport). That's a powerful mental shift.

Finally, don't forget that reflow is just one part of accessibility. The WebAIM Million study found that 95.9% of home pages had WCAG 2 failures, with low-contrast text being the most common issue (WebAIM Million). So while you're modernizing your layout with container queries, also check your contrast ratios—make sure normal text is at least 4.5:1 and large text is at least 3:1 (WCAG 2.1 (AA)). And always test keyboard navigation—make sure every interactive element is reachable and has a visible focus indicator (W3C WCAG 2.1 Understanding Keyboard; W3C WCAG 2.1 Understanding Focus Visible). Container queries won't fix those; they'll just make your layout more resilient.

The single most important thing to remember: Test your design at 400% zoom, not just at iPhone widths. If it breaks, it doesn't matter how clever your media queries are. Container queries make that test easier to pass.

Sources

• MDN Web Docs - https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_containment/Container_queries
• W3C WCAG 2.1 Understanding Reflow - https://www.w3.org/WAI/WCAG21/Understanding/reflow.html
• WCAG 2.1 (AA) - https://www.w3.org/WAI/WCAG21/quickref/
• WebAIM Million - https://webaim.org/projects/million/