Skip to main content
UI/UX

Does Your Website Actually Work on a Phone?

More than half of web traffic now comes from mobile devices. If your site isn't designed for small screens first, you're missing out on most of your visitors. Here's how to fix that—starting with mobile-first, accessibility, and performance.

Does Your Website Actually Work on a Phone?

I remember the first time I looked at my own website on a phone and saw the text squished into a corner. It was ugly, but I shrugged it off—"desktop is where the real work happens," I told myself. Then I checked the analytics: over 60% of my visitors were on mobile. That was a wake-up call.

Now, mobile devices account for 52.57% of global web traffic (StatCounter Global Stats). That's more than half. If your design doesn't put mobile front and center, you're ignoring the majority of your audience. Desktop still matters—45.93% of users are there—but it's no longer the main event.

That's why I build mobile-first: design for the smallest screen first, then scale up. It's not just a buzzword—it's a practical way to focus on what's essential. When you start with a 375px viewport, you can't hide behind sidebars or fancy layouts. You have to make hard choices about content and features. And those choices make your site better for everyone.

Fluid Grids and Images: The Non-Negotiables

Responsive design isn't just about adding a viewport meta tag. It's a system: fluid grids, flexible images, and media queries (MDN Web Docs). Fluid grids use relative units like percentages, fr, rem, or vw/vh instead of fixed pixels. That way, your layout adapts to any screen, not just a few breakpoints.

For images, the rule is simple: img { max-width: 100%; height: auto; } (MDN Web Docs). But there's more. Use srcset and sizes to serve different resolutions, and the picture element for art direction when you need different crops on different screens (MDN Web Docs). Also, always set width and height attributes—they reserve space, preventing layout shifts that hurt your Core Web Vitals (MDN Web Docs).

Speaking of Core Web Vitals, Google uses them to measure user experience and rank your site. A good LCP is 2.5 seconds or less, INP under 200 milliseconds, and CLS 0.1 or less (web.dev). Those numbers matter—slow sites lose visitors.

I once worked on a site where the hero image was 2MB and shot the LCP to 4.5 seconds. After compressing it to WebP and setting width/height, LCP dropped to 1.8 seconds. That's the difference between a user staying or bouncing.

Breakpoints: Let Content Decide

I used to design for specific devices: iPhone, iPad, laptop. But that's a trap. Breakpoints should be added when your content demands them, not at arbitrary device sizes (MDN Web Docs). Common reference points are 375px, 768px, 1024px, and 1440px, but those are starting points, not rules.

For example, if your navigation collapses into a hamburger at 768px, but your content looks cramped at 800px, adjust. The point is to let content dictate where the layout breaks. I've seen sites that look great on a 375px phone but fall apart on a 400px phone—because they hardcoded breakpoints to specific devices. That's a mistake. Use container queries too—they let components respond to their container's size, not the viewport, which is perfect for reusable components (MDN Web Docs).

Accessibility: Not Optional

Accessibility isn't a feature; it's a baseline. Yet the WebAIM Million study found that 95.9% of home pages had detectable WCAG 2 failures, with an average of 56.1 errors per page (WebAIM Million). Low contrast text alone affects 83.9% of home pages (WebAIM Million). That's not just a moral issue—it's a legal one. The DOJ's final ADA Title II rule requires state and local governments to meet WCAG 2.1 AA by April 2026 or 2027, depending on size (Federal Register). And the European Accessibility Act applies to many products and services, with a deadline of June 28, 2025 (EUR-Lex).

So what does accessibility look like in practice? Text resizes up to 200% without breaking layout (W3C WCAG 2.1). All functionality is keyboard-operable (W3C WCAG 2.1). Visible focus indicators (W3C WCAG 2.1). Touch targets at least 24x24 CSS pixels, though Apple recommends 44x44 points and Android recommends 48x48 dp (W3C WCAG 2.2, Apple, Android).

The most common errors are low contrast text, missing alt text, missing form labels, empty links, and empty buttons—these account for 96% of all detected errors (WebAIM Million). Fixing these is low-hanging fruit. You don't need to be an expert; you just need to care.

I remember auditing a client's site and finding 15 errors on the homepage alone: unlabeled search box, low-contrast footer text, and images with no alt text. We fixed them in a day, and their bounce rate dropped by 8%.

Performance: Speed Is a Feature

Users are impatient. Nielsen Norman Group found that 0.1 second is the limit for feeling instantaneous, 1.0 second is the limit for uninterrupted thought flow, and 10 seconds is the limit for keeping attention (Nielsen Norman Group). That means your site needs to be fast, especially on mobile.

One of the biggest culprits is images. Use modern formats like WebP and AVIF. WebP is 25-35% smaller than JPEG, and AVIF is about 50% smaller (MDN Web Docs). But don't just convert—serve different sizes using srcset and sizes. And use loading="lazy" for off-screen images to speed up initial load (MDN Web Docs).

Another performance booster: optimize your fonts. Use font-display: swap to avoid invisible text (MDN Web Docs). And consider using clamp() for fluid typography that scales with the viewport, but be careful not to use viewport units alone for font size—that prevents zooming, which is an accessibility nightmare (MDN Web Docs).

Modern CSS: Container Queries, :has(), and Subgrid

Now, let's get to the fun stuff. CSS has evolved, and you should be using modern features to make your life easier. Container queries are Baseline Widely available since February 2023—use them! They let a component respond to its container's size, not the viewport, which is perfect for reusable components (MDN Web Docs). For example, a card component can be narrow in a sidebar and wide in a main column, and it can adapt its layout accordingly.

And :has() is a game-changer for selecting parents based on children. It's Baseline Widely available since December 2023 (MDN Web Docs). For instance, you can style a section that contains a .featured element without adding a class to the section. That's powerful.

Subgrid is another gem, available since September 2023 (MDN Web Docs). It lets nested grids align with their parent grid, which is perfect for complex layouts where you want alignment across nested elements.

Finally, don't ignore prefers-color-scheme to support dark mode. It's Baseline Widely available since January 2020 (MDN Web Docs). Build your light theme first, then override with a dark theme inside a media query. And don't forget prefers-reduced-motion—respect users who don't want animation (MDN Web Docs).

What I'd Actually Do

If I were starting a new web design project today, here's what I'd do:

  • Start with a mobile-first, content-first design. Sketch the mobile layout before anything else.
  • Use a fluid grid with CSS Grid and flexbox, and set breakpoints only when content demands it.
  • Ensure all images are responsive, lazy-loaded, and have proper dimensions.
  • Make accessibility a requirement from the start: contrast ratios, keyboard support, focus states, and touch targets.
  • Test performance against Core Web Vitals, aiming for LCP
  • Use modern CSS: container queries, :has(), subgrid, and prefers-color-scheme.

I'd also do a quick audit: check your site for the most common accessibility errors—low contrast, missing alt text, missing form labels. Fix those first. They're easy and have a huge impact.

And remember, responsive design is not a one-time task. It's an ongoing commitment. As new devices and screen sizes appear, you need to test and adapt. The mobile majority is here to stay, so embrace it. Your users—and your search rankings—will thank you.

Quick tip: Use the CSS clamp() function for fluid type, but never use viewport units alone for font size—it prevents zooming. Combine with a fixed unit like calc(1rem + 0.5vw).

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/
  • StatCounter Global Stats - https://gs.statcounter.com/platform-market-share/desktop-mobile-tablet
  • 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

Share this article:

Comments (0)

No comments yet. Be the first to comment!