Don’t Get Caught in the Responsive Zoom Trap

I made an interesting discovery today. When you zoom a page with media queries with breakpoints set in ems, you start changing breakpoints as you zoom. According to Brad Frost, using relative units is a good thing “it’s like Grandpa vision!”. I agreed. Until I made this discovery.

Zooming to view text more clearly gets difficult when it also implies a context change. Content may shift around or disappear when you change breakpoint. Usually nobody actually changes breakpoint; the idea is that you work out which screen is available and serve a layout that works with that screen. You probably make assumptions about the device that has the number of pixels you’re working with, too.

Now imagine when you’re zooming due to some visual impairment. Accessibility rules have long stated that we should code so that at least 200% zoom is handled gracefully. This meant having graceful degradation on your containers in general.

On responsive sites, zooming up to 200% inevitably shifts you to a different set of CSS rules. Here the problems begin. Responsive is easy for basic text content (articles and the like). It’s harder for structured, tabular or listing content.

When you are designing, as you work up from your mobile view to your desktop view (of course, because you’ve started mobile first, haven’t you?), you add more content, and change spacing and font sizes too. You do this from small screen up.

Zooming takes users the other way — from big screen down. This means that the page layout will change — probably for the worse. You may lose your place on the screen as a notch of zoom changes your breakpoint to a smaller screen version. Content may disappear as less relevant content takes up too much screen estate on “mobile”.

I just got my fingers burned in what, with hindsight, looks like a big interface conception mistake.

At Pages Jaunes, we are working on a new version of the site which is responsive. Historically our dedicated mobile site, and our mobile apps, do not list phone numbers on the results pages but on the description page only. We followed this convention in spite of alarm bells from the developers about not having key content at all breakpoints.

The classic web site lists numbers behind an “Afficher le numéro” button in the results page, with no need to consult the description page just for that nugget of information. Content is therefore very different between the versions of the site.

Now imagine you’re zooming on a traditional results page at the tablet breakpoint for portrait mode, which also happens to coincide with the view for a vision impaired user at the “old school” resolution of 800x600 which everyone (except those working with the older generation or in accessibility contexts) has forgotten about… they now see this screen when searching for restaurants in Tours :

Results for Restaurants in Tours, French Yellow Pages

So far, so good. Then they click on “Afficher le N°” to get the telephone number to call for La Boucherie.

Results with phone number revealed

Now they decide that they can’t quite read that number — it is quite small on screen — and zoom. After they zoom (using CTRL + or CMD +) they find they have switched to the first “mobile” breakpoint (480px), which has a different content pattern.

View of results page once zoom has been hit

Two bad things happen here.

One: the font size is now actually smaller. This is because after the tablet portrait size we had expected, naively, that the screen size would be much closer to 480 pixels and not as wide as we are seeing here. Most devices we see indeed follow that rule, but we didn’t factor in zoomed browsers at old school resolutions.

Two: we’ve lost our context. Because the content is reflowed with new CSS rules we’ve lost the result. We have to scroll up to find the Boucherie…

Scroll up, find the boucherie

Now we hit the main problem. It’s not obvious where to click to find the phone number at all.

So, watch out for this zooming trap! You need to factor in all sorts of strange use cases if you really want to get the interface right.

Of course, users who need more zoom on responsive sites would do well to zoom before they start navigating at all, but that’s not intuitive at all in most responsive sites, and this case is an outlier. Even if we hadn’t removed the phone number from the smaller screen breakpoints it would still be smaller when zooming, and then start getting bigger again. It also means managing a bunch of other action buttons that aren’t necessarily relevant on mobile until the interface design catches up to all the functionality available on desktop but not mobile (reserve a table, book an appointment, etc.).

Zooming and changing breakpoints gives us a bunch of contexts that we need to mix in with our thinking. Responsive is not easy.

We’re still iterating on the final design and will be taking a better look at this over the coming weeks. I’d love to hear from you if you’ve had issues with this situation or have solutions to this kind of problem. Current workaround is to advise zooming first, in order to surf the mobile breakpoint from the start (avoiding context loss), but our beta is incomplete at the moment and the description page isn’t out there yet. We’re still some way from getting responsive + accessibility + all the technical migration that goes with it dead right, but we’re getting there.

Like what you read? Give Simon White a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.