Stop Designing for Phones: A Responsive Redesign Field Report

The misconception: mobile-first means squeezing desktop down

You've heard "mobile-first" so many times it's become wallpaper. And you've quietly decided it means making the desktop layout shrink gracefully on a phone. That's wrong. Mobile-first means the narrow layout is the source of truth, and the desktop layout is the enhancement. If your CSS starts with a 1200px container and then adds @media (max-width: 768px) patches, you're not mobile-first. You're desktop-first with guilt.

Why does this matter right now? Because Google's mobile-first indexing uses the mobile version of your page for indexing and ranking (Google Search Central). If your mobile page hides content, drops structured data, or serves a stripped-down menu, that's the page Google sees. And with mobile devices at 52.57% of worldwide website traffic in July 2026 (StatCounter Global Stats), your "desktop" design is the minority experience.

Imagine you are redesigning a bakery's site

Let's make it concrete. You're a freelance designer. A local bakery hires you. Their current site is a 2018 WordPress theme: a hero image with text baked into the image, a three-column menu grid, a contact form with no labels, and a font that's a little too thin and a little too gray. They want it to "look modern" and "load faster."

You could restyle it in a weekend. Don't. Here's the audit path that actually prevents rework, step by step.

Step 1: Fix the document, not the paint

Before you touch CSS, open the HTML. The bakery's page is a div soup. Every section is a <div class="section">. Screen readers can't find the main content or the navigation because there are no landmarks. Use <header>, <nav>, <main>, <section>, <article>, and <footer> so assistive tech can identify page regions (MDN Web Docs). A section should lead with a heading. An article should stand alone. An aside is for tangents.

This isn't aesthetic purity. WCAG 2.1 SC 1.3.1 requires that structure and relationships be conveyed programmatically (W3C WCAG 2.1 Understanding Info and Relationships). If your headings are just bold paragraphs, you've failed that before you've written a single color.

Step 2: Make the layout fluid, not breakpoint-choked

Here's where most tutorials go soft. They tell you to add breakpoints at 375px, 768px, 1024px, and 1440px. Those are useful reference points, but the rule is to add a breakpoint when the content demands it, not because a device exists (MDN Web Docs). The bakery's three-column menu grid breaks at roughly 600px because the item names wrap. That's your breakpoint — not 768px because an iPad exists.

Use CSS Grid with fr units and minmax() for the menu. Use Flexbox for the header row. Keep images from overflowing with img { max-width: 100%; height: auto; }. For type, don't reach for pure viewport units — they break zoom. Use clamp() instead, like font-size: clamp(1rem, 2.5vw, 2rem), which scales within safe bounds (MDN Web Docs).

Now the tricky part: the bakery's menu also appears in a sidebar on the catering page. Same component, different container. This is where container queries earn their keep. @container lets a component respond to its container's size rather than the viewport, and it's been widely available in browsers since February 2023 (MDN Web Docs (@container)). Write the component once, and it adapts in both places.

Step 3: Run the accessibility numbers before you argue about taste

The bakery owner will say the gray text "looks elegant." You need numbers, not opinions. 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)). Buttons, icons, and focus rings need 3:1 against adjacent colors. If the gray fails, it fails.

Here's the uncomfortable context: in the WebAIM Million study of the top 1,000,000 home pages, low-contrast text was the most common detected issue, present on 83.9% of home pages (WebAIM Million). You are not fighting a rare edge case. You're fighting the default.

While you're in there: every meaningful image needs alt text, decorative images get empty alt, and color can't be the only signal — about 1 in 12 men have color vision deficiency (NEI (National Eye Institute)). The bakery's "sold out" red dot needs a label too.

Quick tip: test your focus ring before you ship. WCAG 2.1 SC 2.4.7 requires a visible keyboard focus indicator, and WCAG 2.2 SC 2.4.11 adds that a focused component must not be entirely hidden by your own sticky header (W3C WCAG 2.2 Understanding Focus Not Obscured (Minimum)).

Step 4: The comparison that saves you from rework

You have choices at every layer. Here's how to pick without debating forever.

On images: AVIF lossy files are roughly 50% smaller than comparable JPEGs, and WebP lossy files are about 25–35% smaller than JPEGs of similar quality (MDN Web Docs (Image types)). The bakery's hero photo, currently a 1.8MB JPEG, becomes a fraction of that. Set width and height attributes so the browser reserves space and doesn't shift the layout when the image lands.

Step 5: Performance is a design constraint, not an afterthought

Core Web Vitals are three metrics: LCP for loading, INP for interactivity, and CLS for visual stability (web.dev (Web Vitals)). A good LCP is 2.5 seconds or less. A good INP is 200 milliseconds or less. A good CLS is 0.1 or less. You pass when you hit all three at the 75th percentile of page loads, measured separately for mobile and desktop.

For the bakery, the biggest wins are boring: serve properly sized images with srcset and sizes, lazy-load everything below the fold with loading="lazy", and stop loading four icon libraries you don't use. The perceived-responsiveness research matters too — 0.1 seconds feels instantaneous, and 1.0 second keeps a user's flow of thought uninterrupted (Nielsen Norman Group). Miss that on the mobile menu, and people leave.

Step 6: Test what you actually built

Run these checks before you call it done:

• Zoom to 200% and confirm no content or functionality is lost (WCAG 2.1 SC 1.4.4).
• Set the browser to 320 CSS pixels wide and confirm no horizontal scrolling for vertical content (WCAG 2.1 SC 1.4.10 Reflow).
• Tab through the entire page and confirm every interactive element is reachable and visibly focused.
• Submit the contact form with a bad email and confirm the error is described in text, not just a red border (WCAG 2.1 SC 3.3.1).

If you serve a US state or local government client, the clock is already running: under the DOJ ADA Title II rule, entities serving 50,000 or more people must comply with WCAG 2.1 Level AA by April 24, 2026, and smaller entities by April 26, 2027 (Federal Register (DOJ ADA Title II rule)). For EU e-commerce, banking, and e-books, the European Accessibility Act applies to services provided after June 28, 2025 (EUR-Lex Directive (EU) 2019/882).

The one thing to remember

Mobile-first isn't a slogan you put in a proposal. It's a build order: semantic HTML first, then fluid layout, then accessibility numbers, then performance. The bakery project took three extra days because we started with structure instead of a hero animation. It shipped without a single reflow bug and passed Core Web Vitals on the first mobile run. Do it in that order, and "responsive" stops being a checklist and starts being the way you work.

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/
• Google Search Central - https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing
• 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