Low-Vision Users and the Zoom Test Your Site Probably Fails

There’s a test you can run on your website right now that takes ten seconds and will probably embarrass you. Open your homepage, hold Ctrl (or Cmd), and press the plus key until the browser says 200%. Now try to use the site. Try to read the navigation. Try to fill out the signup form. Try to find the price.

When I run this test on sites people send me, something breaks almost every time. Text overlaps other text. A sticky header grows until it covers half the screen. A cookie banner that was annoying at normal size now hides everything. Buttons slide off the right edge where no one will ever find them. The site didn’t break because zoom is exotic. It broke because nobody ever tried it.

Here’s why this matters more than most people think. When we say “blind users” everyone imagines screen readers, and screen readers are important. But the far larger group is people who can see, just not well. People with aging eyes. People with cataracts forming. People recovering from eye surgery. People who forgot their glasses. These users don’t install special software. They do the most obvious thing in the world: they make the text bigger. Browser zoom is their assistive technology, and it ships with every browser ever made.

The accessibility guidelines have a plain requirement here. WCAG says a page should work when zoomed to 200 percent without losing content or function, and the stricter reflow rule says that at the equivalent of a 320-pixel-wide viewport, users shouldn’t have to scroll sideways to read a line of text. Strip away the standards language and it’s simple: when someone enlarges your page, everything should still be readable and usable, and reading shouldn’t require dragging a horizontal scrollbar back and forth for every line. Reading a paragraph that way is like reading a book through a mail slot.

The interesting thing is why sites fail this test. It’s almost never a hard problem. It’s a series of small decisions that each seemed fine. Someone set a fixed pixel height on a header, because it looked crisp in the mockup. Someone put text in a container with a fixed width. Someone used pixels for font sizes instead of relative units, or wrote CSS that assumes the viewport is at least 1200 pixels wide. Each decision was invisible at the zoom level the designer worked at. The failures only appear at zoom levels the team never uses.

This is the general pattern with accessibility problems, and it’s worth naming. Your site is tested constantly, thousands of times a day, by its visitors. But it’s tested by you only in the configuration you happen to use: your screen, your browser, your eyesight, your zoom level. The gap between those two things is where users quietly fall out. And they do fall out quietly. A low-vision user who zooms in, finds your checkout button pushed off screen, and leaves does not file a bug report. They just buy from the site that works. You will never know they existed. The cost shows up as nothing, which is the most expensive kind of cost, because nothing is exactly what you’ll do about it.

There’s a related failure I see even more often: sites that actively fight the user’s attempt to zoom. On mobile, some sites ship a viewport meta tag with user-scalable=no or a maximum scale of 1, which disables pinch-to-zoom entirely. Somebody added it years ago to stop an input from zooming awkwardly on iPhones, and it’s been silently locking out low-vision visitors ever since. If a user is trying to enlarge your text, they have a reason. Blocking them doesn’t fix your layout. It just makes your site the one that doesn’t work.

The fix for all of this is not a rewrite. Use relative units for text. Let containers grow with their content instead of clipping it. Test your layouts at narrow widths, which you’re probably already doing for mobile; the reflow requirement and mobile responsiveness are nearly the same problem wearing different hats. If your site works well on a phone, you’re most of the way to working well at high zoom on a desktop. Then delete anything that disables zooming, and actually run the ten-second test on your five most important pages: home, pricing, signup, checkout, contact.

When I built GazeSite I made it capture pages at both desktop and mobile viewport sizes, partly for this reason. A surprising number of layout failures only exist at sizes the site owner never looks at. But you don’t need any tool to start. You need Ctrl and plus, and the willingness to look at what happens.

I think the zoom test is a good first accessibility test precisely because it requires no empathy leap. You don’t have to imagine using a screen reader. You just have to press a key you already know, and watch your own site stop working. Once you’ve seen it, it’s hard to unsee. And unlike most problems in software, this one gets more relevant every year, because every one of your users is aging, and so are you. The person you’re fixing the site for is not an abstraction. It’s you, in twenty years, trying to read your own homepage.