Web Browser Zoom: Design consequences

Tibo BeijenMarch 7th, 2009
web-browser-zoom-design-consequences

Over the years the display size of the average computer screen has increased. As a consequence nowadays more and more websites are designed with a 1024 width screen in mind. For example: BBC, Adobe and The New York Times. With at least 78% of the users using a 1024 or higher resolution screen the time seems right to move away from the 800px designs. But what about accessibility? And usability? And is full page zooming really better than text scaling?

Screen resolution

Take the february 2009 stats of thecounter.com. Based on those stats a target resolution of 1024 seems reasonable: At least 78% of the people view websites at that resolution or higher.

Of course the need for the increased width depends on the specific elements that have to be displayed. When left- and right columns are narrow, a width of 1024 might lead to very long lines which are hard to read.

Accessibility guideline: text size

Accessibility guidelines (W3C WCAG 1.0 point 3.4) state that relative units are to be used when specifying text size. That way, users can easily adjust the size of text. For some time, browsers (except *sigh* IE6) allowed users to adjust the displayed text size by using key combinations or ctrl+scrollwheel. This posed a challenge to CSS coding as it wasn’t always easy to keep everything in place when text size was increased. Or, probably worse, text would flow out of the box and become unreadable. See below image of a page on eurogamer.net. In the left-column navigation and bottom parts of the page elements will overlap when text size is increased.

Eurogamer text size example

Eurogamer text size example

Nowadays quite some web browsers have replaced text scaling with page zooming. This definitely makes life easier for CSS coders. It will also help user experience when increasing text size because relative placement of elements is preserved, as opposed to situations where some columns are stretched in different amounts. But there is a side-effect.

The misinterpretation of statistics and its disastrous consequences

When a website already fills the entire viewport in it’s original size, as soon as display size is increased, horizontal scroll bars will appear and the rightmost content will move out of view. So now let’s turn the aforementioned stats around. At least 51% of the visitors have a screen resolution of 1024 or less. So basically this means that when a page is designed to have a minimum width of, say, 1000px, half of the visitors will have problems increasing the displayed size.

Although official accessibility standards don’t seem to mention horizontal scrolling, it’s safe to say that having to scroll horizontally doesn’t help accessibility. And from a usability perspective it’s most certainly bad practice.

Regarding accessibility standards not mentioning horizontal scrolling: I searched the standards document of the dutch government which includes all WCAG guidelines (and more). I searched for the words screen (dutch: scherm), horizontal (dutch: horiz) and scroll. Nothing. A downside of these kind of checklists: technology moves on continuously while standards only get update once every x years. But that’s a different subject…

Browser overview: Text scaling or Full page zooming?

Acknowledging this side-effect it’s good to know exactly how today’s browsers perform zooming. See the table below.

IE7 FF3 Opera 9 Safari Chrome
Default scaling zoom zoom zoom text text
Zoom options
All content yes yes yes no no
Text only menu menu no yes yes
Zoom percentages
Step 1 110 111 110
Step 2 120 123 120
Step 3 130 131 130
Step 4 140 143 140
Step 5 150 154 150
Widths (original is 800px)
Step 1 880 888 880
Step 2 960 980 960
Step 3 1040 1044 1040
Step 4 1120 1142 1120
Step 5 1200 1230 1200

Browser zoom characteristics

Conclusion

Although stats suggest 1024 is a solid choice, it’s obvious that there are considerations to be taken into account. If liquid design with a minimum of 800px is not an option and one chooses to design for a (minimum) resolution of 1024px the least one can do is try to avoid putting essential navigation or use cues in the rightmost part of the site.

See image below of Play.com: The top part with the currency selectors and link to the visitor’s account-page do sticks to the right size of the screen.

In this case I think it’s a coincidence as the cart button does extend beyond the visible area. The selectors are positioned absolutely from the right size of a container that doesn’t have it’s css attribute position set to ‘relative’. So positioning is done with respect to the BODY element. Although that has a min-width of 990px it somehow works out this way.

Play.com header example

Play.com header example

One last tip: IE7 keeps a centered column centered when zooming in, as opposed to Firefox and Opera. So when in IE7 horizontal scroll bars appear, bits are falling of the left side of the screen as well.

  • Twitter
  • LinkedIn
  • Facebook
  • StumbleUpon
  • DZone

2 Responses to “Web Browser Zoom: Design consequences”

  1. Having issues with text zoom vs. page zoom. It seems that you can not design for both when you are dealing with divs. Infact text zoom does not work at all when dealing with divs. They are all positioned with ems absolutely with text that is told to be a cetain size in css.
    HOWEVEr in firefox even if you tell text size to stay 14em it will grow anyways. And that moves all the images and whatever else i have on page things overlap it is a mess.

    then i designed the same page in tables now things are stuck and page layout does not differ due to nesting.
    however now however over divs don’t line up correctly when browser is shrunk or grown because however over doesn’t work in tables only works in divs. The tables and div’s line up differently because they react differently to the browser being shrunk and expanded. Any ideas on how to fix this issue would be appreciated. Trying to design website for all sorts of users.

    edit: *hoverover

  2. This article is more about design decisions than about how to create a design with CSS. The topic of CSS is covered abundantly on the net and I’d suggest searching for terms like css, float, layout, overflow etc. If divs need to be stretched when content grows ‘clear:both’ is the search-term to go for…
    For a place to drop tech-questions I can really recommend Sitepoint Forums.

Leave a Reply

(required)
(will not be published, required)