Zoom for fixed and responsive sites

Translations

I also considered calling this “Why zoom sucks on mobile”, as that is the biggest issue with zooming & web development.
To understand why I’ll walk through the different ways zoom works on desktop and mobile.

Desktop/laptops

Browser-zoom is the default across the board for browsers on desktop operating systems like Windows and OSX. A few browsers have a feature for only increasing the size of text, but that has already become a historical artifact you have to dig up in the interface. It is also very difficult (perhaps impossible?) for developers to allow for both text-sizing and zoom in practice, so I’m going to put that to one side.

Browser-zoom basically works by expanding everything. At 200% zoom 1 pixel becomes 2×2 pixels. I.e. twice as wide and twice as tall.

Zooming in on a fixed layout

Traditionally this causes horizontal scrolling, because the layout of the site expands beyond your view of it (the browser window). You can imagine it a bit like a traditional screen magnifier.

This is very difficult for people who need to make things bigger (and perhaps also use a screen magnifier so you have double-scrolling). I’d like to see that become a fail at WCAG double-A.

Zooming in on a responsive layout

For a responsive site zooming in still increases everything, the difference is that the site can use media queries to adapt the layout. If your browser window is 1000 pixels wide on screen and you zoom in to 200%, your effective browser width is 500 pixels.

You can then have a media query that adapts the layout to 500 pixels wide, for example, by making columns stack on top of each other instead of being side by side.

Therefore someone zooming in does not get horizontal scrolling, and everything is bigger.

At sufficient levels of zoom, the site appears to be the same as it would on a mobile device. I think this is a good thing for accessibility.

Mobile (smaller screen) devices

Mobiles (by which I mean small-ish touch-screen devices running iOS or Android) have a more complex way of doing layout, where the document width and screen width are different. See PPK’s excellent explanation for more on that.

Zooming-in on mobile with a fixed layout

For non-responsive sites small-screen devices tend to start ‘zoomed out’ so you see the whole layout, which is squeezed into roughly 1000 pixels wide. You can then pinch-zoom and it works like a screen magnifier, you have to scroll around, or double-tap on something to zoom to it.

Zooming-in on mobile with a responsive layout

For a responsive site the browser has a certain width (e.g. 320px wide for an iPhone 5), and the applicable media query is used for the layout. Assuming the site allows pinch-zoom (and it should) then you immediately get horizontal scrolling.

Because zoom increases the size of the page (document width) within the screen-width, it works like a fixed layout; just starting at a bigger initial size.

This is not good for accessibility. There needs to be a mechanism to make things (especially text) bigger without immediately causing scrolling. It is not technically a fail in WCAG 2, but it’s definately an issue. iOS has a built in magnifier, but that does the same thing as zooming.

I think this is a user-agent issue, and the best method would be to have an accessibility option that lets you increase in size without horizontal scrolling.

Some devices allow for increasing text-size (e.g. Firefox on Android), but in most cases (Safari, Chrome) it doesn’t apply to web content.

Only Opera on Android (thanks for the tip Shwetank Dixit) implements this in some form, where pinch-zoom will zoom the layout outside of the viewport, but reflow the text within the viewport. It is a bit like having {max-width: 100vw} on paragraphs, headings, lists etc.


Notes

The layouts used in the videos can be accessed at: fixed and responsive, they rely on flex-box for layout.

I’ve used iOS (Safari) as the specific examples above, but mobile browsers tend to work in the same way for calculating layout and zoom, probably because most were at one stage based on webkit.