Build a Responsive Site That Passes WCAG and Keeps Users

Picture this: you're a designer at a state agency. You just found out your site has to meet WCAG 2.1 AA by April 2026 because your population tops 50,000 (Federal Register). And you're not alone—everyone in web design is sweating it. But accessibility isn't a punishment; it's the bedrock of good UI/UX. In this walkthrough, I'll show you, step by step, how to build a responsive site that looks sharp, meets WCAG, and keeps users happy.

Who This Is For

This is for working designers and developers who want to stop bolting on accessibility and start baking it in. We'll talk about the stuff you actually deal with daily: CSS setup, breakpoints, touch targets, images. By the end, you'll have a checklist you can use on any project.

Start with a Mobile-First Fluid Grid

Start small: build for mobile first, then enhance for bigger screens. Use fluid grids with relative units—percentages, fr, em/rem, vw/vh—instead of fixed pixels (MDN Web Docs). For images, add img { max-width: 100%; height: auto; } so they never overflow their container (MDN Web Docs). For typography, use clamp() to scale text smoothly: font-size: clamp(1rem, 2.5vw, 2rem) (MDN Web Docs). But don't use viewport units alone for font size—pair them with a fixed unit, like calc(1.5rem + 4vw), so users can zoom (MDN Web Docs).

Set Breakpoints Where Content Demands

Don't just pick breakpoints at random device sizes. Add them when your content starts looking cramped. Common reference values are around 375px, 768px, 1024px, and 1440px (MDN Web Docs). Use Flexbox for one-dimensional layouts and CSS Grid for multi-column ones, with the fr unit to distribute space (MDN Web Docs). And don't forget the viewport meta tag: <meta name="viewport" content="width=device-width, initial-scale=1.0"> so mobile browsers match the device width (MDN Web Docs).

Make Touch Targets Easy to Hit

Touch targets are a big deal. WCAG 2.2 requires a minimum of 24 by 24 CSS pixels, but that's the floor (W3C WCAG 2.2 Understanding Target Size (Minimum)). Apple suggests 44 by 44 points, Android says 48 by 48 dp (Apple Human Interface Guidelines; Android Developers). I aim for 48 by 48 pixels on every interactive element—buttons, links, form fields—and space them apart to avoid mis-taps. That helps everyone, not just folks with motor impairments.

Design for Color and Contrast

About 1 in 12 men have color vision deficiency (NEI), so never rely on color alone. Pair color with labels, icons, or patterns (WCAG 2.1 (AA)). For text, WCAG 2.1 AA needs a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (WCAG 2.1 (AA)). UI components like buttons and focus states need 3:1 against adjacent colors (WCAG 2.1 (AA)). The most common accessibility error on the web is low-contrast text—it's on 83.9% of home pages (WebAIM Million). Don't be part of that statistic.

Ensure Keyboard and Focus Accessibility

All functionality must work via keyboard (WCAG 2.1 (AA)). That means visible focus indicators—don't remove the outline (W3C WCAG 2.1 Understanding Focus Visible). Also, make sure focus isn't hidden by sticky headers or modals (W3C WCAG 2.2 Understanding Focus Not Obscured (Minimum)). And structure your page with proper headings and landmarks, conveyed programmatically (W3C WCAG 2.1 Understanding Info and Relationships).

Optimize Performance and Responsiveness

Core Web Vitals are critical for UX. Aim for LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less (web.dev (Web Vitals)). For perceived responsiveness, 0.1 second feels instantaneous, 1.0 second keeps the user's flow, and 10 seconds is the limit for attention (Nielsen Norman Group). To reduce CLS, set width and height on images so they reserve space (MDN Web Docs). Use loading="lazy" for off-screen images to speed up initial load (MDN Web Docs). And use srcset/sizes or picture for responsive images (MDN Web Docs).

What Can Go Wrong

One common mistake: adding breakpoints at fixed device sizes, which breaks when new devices come out. Another: using only color to indicate errors—you must also provide text descriptions (W3C WCAG 2.1 Understanding Error Identification). And don't forget the reflow requirement: content must be usable without scrolling in two dimensions at a width equivalent to 320 CSS pixels (W3C WCAG 2.1 Understanding Reflow). Also, respect prefers-reduced-motion to disable non-essential animation (MDN Web Docs; W3C WCAG 2.1 Understanding Animation from Interactions).

Quick Tip

Test with keyboard only—if you can't navigate, you fail WCAG 2.1.1 (W3C WCAG 2.1 Understanding Keyboard).

Takeaway

Building an accessible, responsive site isn't optional—it's the standard. By starting with a mobile-first fluid grid, setting content-based breakpoints, hitting touch target sizes, ensuring contrast, and optimizing Core Web Vitals, you'll create a site that serves everyone and passes WCAG 2.1 AA. The deadline is coming; start now.

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