Why does my site break on mobile and fail accessibility checks?
You've just finished a desktop design. It looks sharp. Then you open it on your phone and the text is tiny, the button is impossible to tap, and the contrast is so low you can barely read it. And when you run an automated accessibility check, it lights up like a Christmas tree. This is the exact problem I see with almost every client project that starts from a desktop-first mindset. The fix isn't a plugin or a framework. It's a mobile-first, accessible CSS approach from the very first line.
Start with the viewport meta tag
Before anything else, your HTML head needs this: <meta name="viewport" content="width=device-width, initial-scale=1.0">. Without it, mobile browsers render your page at a desktop width and shrink it down, which is why text looks like ants. This tag tells the browser to match the device width, so your responsive CSS actually has something to respond to (MDN Web Docs). I've seen this single line fix more "mobile issues" than anything else.
Set a fluid type scale with clamp()
Now, the typography. You might be tempted to use viewport units alone, like font-size: 4vw. Don't. That prevents zooming on mobile, which is a WCAG failure (MDN Web Docs). Instead, use clamp(). For a body text, something like font-size: clamp(1rem, 2.5vw, 2rem) gives you a fluid scale that respects the user's zoom. And for readability, WCAG recommends a minimum body font size of 16px, a line height of about 1.5, and a line length of 45 to 75 characters (WCAG 2.1 AA). That's not a luxury; it's a baseline.
Build with flexible grids and images
Stop using fixed pixel widths for your layout. Use CSS Grid with fr units and Flexbox with flex-wrap. These are the tools of responsive design (MDN Web Docs). For images, always set max-width: 100%; height: auto; so they never overflow their container (MDN Web Docs). And add width and height attributes to every image. This reserves space before the image loads, which directly helps your Cumulative Layout Shift (CLS) score (MDN Web Docs).
Make your touch targets huge
On mobile, your user's finger is not a precise mouse. WCAG 2.1 recommends touch targets of at least 44 by 44 pixels (WCAG 2.1 AA). That's the minimum for usability. But if you're building for Android, the Material Design guidelines suggest 48 by 48 dp, which is roughly 9 mm (Android Developers). I've seen too many sites where the "close" button is 20 pixels wide. That's a usability disaster. And don't forget spacing between targets to prevent accidental taps.
Don't rely on color alone
About 1 in 12 men have color vision deficiency (NEI). If your form errors are indicated only by a red border, you're failing them. Pair color with icons, labels, or patterns. And make sure every image has meaningful alt text; for decorative images, use empty alt (WCAG 2.1 AA). This isn't just about being nice—it's about being clear.
Respect the user's motion preferences
If you have any animation, use the prefers-reduced-motion media query to tone it down for users who request reduced motion (MDN Web Docs). It's a simple CSS line, but it prevents real physical discomfort for people with vestibular disorders. WCAG has a Level AAA criterion for this, but you should treat it as a default practice (WCAG 2.1 AAA).
Test at 400% zoom and 320px width
Here's the kicker: WCAG 2.1 requires that content reflows without loss of information at a width of 320 CSS pixels (which is what you get at 400% zoom on a 1280px screen) (W3C WCAG 2.1 Understanding Reflow). That means no horizontal scrolling. I always test my responsive layouts at 320px wide and 200% zoom (for text resize). If the layout breaks, I fix the CSS. It's not that hard if you start mobile-first from the beginning.
The reality check
WebAIM's Million study found that 95.9% of home pages had detected WCAG 2 failures, and low-contrast text was the most common issue, present on 83.9% of pages (WebAIM Million). That's the state of the web. But you don't have to be part of that statistic. A mobile-first, accessible CSS approach—fluid grids, flexible images, proper contrast, big touch targets, and testing at 320px—will get you most of the way there. And it will also help your Core Web Vitals: LCP under 2.5 seconds, INP under 200ms, and CLS under 0.1 (web.dev). Those are not optional; they're user expectations.
Quick tip
Set img { max-width: 100%; height: auto; } in your global CSS before you write anything else. It's the single most effective line for preventing layout overflow.
Warning
If you don't set the viewport meta tag, none of your responsive CSS will work on mobile. It's the foundation.
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
- WebAIM Million - https://webaim.org/projects/million/
- web.dev (Web Vitals) - https://web.dev/articles/vitals
Comments (0)
Please sign in to post a comment.
Don't have an account? Create one
No comments yet. Be the first to comment!