Why Your 320px Reflow Test Is Failing: A Field Guide to WCAG 2.1 AA

Here's a number that should keep you up at night: 95.9% of home pages have detected WCAG 2 failures (WebAIM Million). That's nearly every site on the internet, and your portfolio site is no exception. The culprit isn't lack of effort—it's a fundamental misunderstanding of what responsive design actually demands. You're not building for a screen; you're building for a viewport that can shrink to 320 CSS pixels, and if your layout doesn't reflow gracefully at that width, you're failing the WCAG 2.1 Reflow test (SC 1.4.10). This isn't about aesthetics; it's about accessibility, and it's about to become a legal requirement for many public entities.

The 320px Reflow Test: What It Really Means

Imagine you're a web designer for a local government agency. You've just heard about the DOJ's final ADA Title II rule, which requires state and local governments to make web content comply with WCAG 2.1 Level AA (Federal Register). Your agency serves a population of 50,000 or more, so your deadline is April 24, 2026 (Federal Register). You open your responsive site on a phone and zoom in to 400%. At that zoom, the effective viewport width is 320 CSS pixels (W3C WCAG 2.1 Understanding Reflow). The rule is simple: content must be presented without loss of information and without requiring two-dimensional scrolling at that width (W3C WCAG 2.1 Understanding Reflow). If your layout forces horizontal scrolling, you fail.

So, how do you test it? Open your browser's developer tools, set the viewport to 320px, and click through every page. Check for horizontal scrollbars, clipped content, and hidden menus. That's the test. But passing it requires a deliberate approach from the start.

Start with Fluid Grids, Not Fixed Pixels

Your first instinct might be to use media queries to stack columns at small widths. That's fine, but it's not enough. The foundation of responsive design is fluid grids: using relative units like percentages, fr, em/rem, and vh/vw instead of fixed pixels (MDN Web Docs). If you set a container to width: 960px, it will overflow a 320px viewport no matter how many media queries you write. Instead, use flexbox with flex-wrap or CSS Grid with fr units to distribute space proportionally (MDN Web Docs). For example, a three-column grid defined as grid-template-columns: repeat(3, 1fr) will naturally shrink and reflow when the viewport narrows. You don't need a media query to make it work—the fluidity does the heavy lifting.

But fluid grids only work if your content is flexible too. Images are the usual culprits: an image with a fixed width will blow out your layout. Add img { max-width: 100%; height: auto; } to your CSS to keep media within its container (MDN Web Docs). And don't forget to set width and height attributes on images so the browser reserves space before they load—this prevents layout shift, a Core Web Vital metric (MDN Web Docs).

Breakpoints: Let Content Decide, Not Devices

Now, you might be tempted to add breakpoints at every popular device width—iPhone, Android, whatever. Resist that urge. Breakpoints should be added when content demands them, not at fixed device sizes (MDN Web Docs). The common reference values of 375px, 768px, 1024px, and 1440px are starting points, not gospel (MDN Web Docs). As you resize your browser, watch for where the layout starts to look awkward—where text gets too cramped, where columns become unreadable. That's your breakpoint.

In your 320px test, you'll likely find that a two-column layout with a sidebar and main content becomes unusable. At that point, you need to switch to a single-column layout. But don't just hide the sidebar; ensure the content is still accessible and in a logical order. The WCAG 2.1 SC 1.3.1 Info and Relationships requires that structure and relationships be conveyed programmatically, so use semantic HTML and ARIA landmarks correctly (W3C WCAG 2.1 Understanding Info and Relationships).

Typography: The 16px Rule and Fluid Type

Another common failure at 320px is text that's too small to read without zooming. WCAG 2.1 Level AA requires a minimum body font size of 16px, a line height of about 1.5, and a line length of roughly 45 to 75 characters (WCAG 2.1 (AA)). If you use viewport units alone for font sizing, you'll break zooming—users can't resize text if it's tied to the viewport width (MDN Web Docs). The solution is to use CSS clamp() to create fluid type: font-size: clamp(1rem, 2.5vw, 2rem) (MDN Web Docs). This scales with the viewport but stays within safe limits, and it respects the user's zoom settings because it includes a fixed unit.

But fluid type isn't just about size; it's about reflow. WCAG 2.1 SC 1.4.4 Resize Text requires that text can be resized up to 200% without loss of content or functionality (W3C WCAG 2.1 Understanding Resize Text). At 320px, that means your layout must still work when the user zooms in. So test not only at 320px but also at 200% zoom. You'll be surprised how many sites fail that.

Touch Targets and Focus States: Don't Let the Little Things Slip

At 320px, touch targets become critical. Apple recommends a minimum of 44x44 points (Apple Human Interface Guidelines), and Android suggests 48x48 dp (Android Developers (accessibility)). WCAG 2.2 SC 2.5.8 Target Size requires at least 24x24 CSS pixels, but that's a minimum—if you're designing for mobile, aim for the higher standard. Small links and buttons are not just a usability issue; they're an accessibility failure. If a user with motor impairments can't tap your link, they're excluded.

Keyboard focus is another area where designers often drop the ball. WCAG 2.1 SC 2.4.7 Focus Visible requires a visible focus indicator (W3C WCAG 2.1 Understanding Focus Visible). And WCAG 2.2 SC 2.4.11 Focus Not Obscured requires that when an element receives focus, it isn't hidden by author-created content like sticky headers or cookie banners (W3C WCAG 2.2 Understanding Focus Not Obscured (Minimum)). At 320px, sticky elements can eat up precious space, so make sure your focus states are not only visible but also unobscured.

Contrast and Color: The Most Common Failure

Low contrast text is the most common accessibility error, present on 83.9% of home pages (WebAIM Million). WCAG 2.1 Level AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (WCAG 2.1 (AA)). And UI components like buttons and focus states need at least 3:1 against adjacent colors (WCAG 2.1 (AA)). If you're using a color palette with subtle shades, run a contrast checker. Also, don't rely on color alone to convey meaning—about 1 in 12 men have color vision deficiency, so pair color with labels or icons (NEI (National Eye Institute)).

Now, let's talk performance. Core Web Vitals are a set of metrics that measure user experience: LCP, INP, and CLS. A good LCP is 2.5 seconds or less, a good INP is 200 milliseconds or less, and a good CLS is 0.1 or less (web.dev (Web Vitals)). At 320px, your page should load fast and be stable. Use lazy loading for off-screen images to improve initial load (MDN Web Docs), and set width and height on images to prevent layout shift (MDN Web Docs).

Quick tip: Use the loading="lazy" attribute on images below the fold, but be careful with above-the-fold images—lazy-loading them can hurt LCP.

Putting It All Together: A Worked Example

Let's walk through a concrete scenario. You're redesigning a city's public library website. The site has a header, a main content area with a list of events, and a sidebar with hours and contact info. You start with a fluid grid: the main content area uses grid-template-columns: repeat(auto-fit, minmax(250px, 1fr)) so that at 320px, the grid stacks automatically. You set the body font to 16px with a line height of 1.5, and you use clamp() for headings. You check contrast: the body text is #333 on #fff, which passes 4.5:1; the button background is #0077cc with white text, which passes 3:1 for UI components. You test at 320px: the header wraps, the sidebar moves below the main content, and no horizontal scrolling occurs. You test keyboard navigation: the focus ring is visible and not obscured by the sticky header. You run a Lighthouse audit: LCP is 1.8s, INP is 150ms, CLS is 0.02. You fix the few remaining contrast issues.

This isn't hypothetical—it's the kind of work you'll need to do to meet WCAG 2.1 AA. And if you're a public entity, the deadline is looming. Even if you're not, the WebAIM Million data shows that most sites fail. Don't be part of that statistic.

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
• web.dev (Web Vitals) - https://web.dev/articles/vitals
• 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
• WebAIM Million - https://webaim.org/projects/million/