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

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.

<th class="c2">
  IE7
</th>

<th class="c3">
  FF3
</th>

<th class="c4">
  Opera 9
</th>

<th class="c5">
  Safari
</th>

<th class="c6">
  Chrome
</th>

<td>
  zoom
</td>

<td>
  zoom
</td>

<td>
  zoom
</td>

<td>
  text
</td>

<td>
  text
</td>

<td>
  yes
</td>

<td>
  yes
</td>

<td>
  yes
</td>

<td>
  no
</td>

<td>
  no
</td>

<td>
  menu
</td>

<td>
  menu
</td>

<td>
  no
</td>

<td>
  yes
</td>

<td>
  yes
</td>

<td>
  110
</td>

<td>
  111
</td>

<td>
  110
</td>

<td>
</td>

<td>
</td>

<td>
  120
</td>

<td>
  123
</td>

<td>
  120
</td>

<td>
</td>

<td>
</td>

<td>
  130
</td>

<td>
  131
</td>

<td>
  130
</td>

<td>
</td>

<td>
</td>

<td>
  140
</td>

<td>
  143
</td>

<td>
  140
</td>

<td>
</td>

<td>
</td>

<td>
  150
</td>

<td>
  154
</td>

<td>
  150
</td>

<td>
</td>

<td>
</td>

<td>
  880
</td>

<td>
  888
</td>

<td>
  880
</td>

<td>
</td>

<td>
</td>

<td>
  960
</td>

<td>
  980
</td>

<td>
  960
</td>

<td>
</td>

<td>
</td>

<td>
  1040
</td>

<td>
  1044
</td>

<td>
  1040
</td>

<td>
</td>

<td>
</td>

<td>
  1120
</td>

<td>
  1142
</td>

<td>
  1120
</td>

<td>
</td>

<td>
</td>

<td>
  1200
</td>

<td>
  1230
</td>

<td>
  1200
</td>

<td>
</td>

<td>
</td>

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.

<p class="wp-caption-text">
  Play.com header example
</p>

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.