A List Apart

Issue № 191

Big, Stark & Chunky

by Published in Browsers, CSS, Graphic Design, Layout & Grids, Typography & Web Fonts, Accessibility49 Comments

Readers of A List Apart will by now be quite familiar with screen-reader users, the largest group of disabled web surfers whom standards compliance actually helps. In a previous article, for example, I examined how well image-replacement techniques work in screen readers (not very).

But — surprise! — most people with impaired vision can still see something, and a large but unquantified segment of this group sees well enough to use a computer with a magnified or zoomed display. We have not done a good job of catering to these screen-magnification or zoom users. Using CSS, it’s easy to do, as we shall soon see. And moreover, using CSS to develop zoom layouts is almost exactly what developers of handheld and PDA browsers are doing in their quest for small-screen rendering of wide, multicolumn web pages.

But first, let’s understand the problem.

A different way to view the web

Websites are mostly type. A low-vision person will probably be able to read type on a web page if it’s big enough and if it’s presented in a certain color scheme.

But when you blow up the fonts on a web page, eventually your display runs out of room. Or even if it doesn’t (are you using a 50-inch plasma display? how about two 30-inch Cinema Displays?), you the low-vision user are sitting at a certain distance from the screen, giving you only a limited field of comfortable view. Moreover, your vision loss may involve visual field; you may simply see less than people with normal vision or even people with other visual impairments.

Eventually, then, every website will outgrow its container if you zoom in far enough. The container may be table cells, divs, the monitor, or the user’s visual field, or any combination. You can use CSS to make sure your site does not knowingly zoom past the perimeter of a user’s vision.


There’s a modicum of published research documenting the needs of zoom users. Of most recent interest is a paper by Ginny Redish and Mary Theofanos (see references).

While many participants in their study had trouble when color was removed from a web page (as some screen magnifiers do when they switch to high contrast), the biggest problem was multicolumn page designs. A few users never discovered some of the columns. Some components, even when located inside a single column that subjects could theoretically see and use, had already scrolled right off the screen and were ignored.

Some highlights from that paper:

  • These users, however, do not want a “different” site: They don’t want a “screen-magnifier version” or a “text version” if that means a site that has to be separately maintained from the main version. They believe the sites would not be equivalent. They believe the “special” site would not be kept up-to-date.  The issue is how to provide “experience equity” and universal usable access to all low-vision users.
  • [One participant stated] “Headings and bold are very important.”
  • [Participants] told us that they often copied and pasted material into Word where they could enlarge the font even more and make it bold, thus rendering it easier for them to see.  Two other participants made conscious decisions about viewing strategies to accommodate the problems caused by wanting to maximize both how much of the page you see and how easily you can read it. [One person] kept the magnification at 2×, which he said was lower than he needed; he said he was sacrificing ease of reading for seeing more on the screen. 
  • Most of our participants did not use cursor control keys even when doing so might have helped them. Instead, they moused around the screen very rapidly, and, in doing so, often lost any sense of where they were on the web page.
  • Users who do not work with the scroll bar may never go to the right side of the screen.
  • Users can miss items – even ones that are next to each other – when the screen is magnified.

Destroy your own design

Now, standardistas have spent years coming up with multicolumn page designs that look nice, render more or less the same in compliant browsers, and (for the keener developers) are also usable to screen readers. We took a slightly defective model (multicolumn pages laid out with tag-soup tables) and cleaned it up somewhat (multicolumn pages laid out with valid HTML and CSS).

Standardistas were able to stomach the idea that blind people were simply ignoring the appearance of their sites because, self-evidently, they were blind. It was no big deal; nothing happens to your visual design when you accommodate blind people.

But to accommodate low-vision people, you have to totally rearrange your multicolumn site. You have to knowingly destroy your original graphic design. But do we need to throw out the baby with the bathwater? No. You can use CSS to customize all versions of your site.

  • Your default page can use whatever graphic design you like.
  • Through a site-preferences page or a simple style sheet switcher, the user can switch the same information to a single-column view with big fonts. You can tweak which portions of your navigation scheme actually appear, and where, in each design; you generally want less navigation.
  • Since we’re not making a text-only page that would probably end up neglected, but are merely providing a different view of the same page, we obviate low-vision users’ fears of being stuck in special gulag.

Design basics

Your low-vision design should do the following:

Switch to a big font
You can let the visitor enter a point size by keyboard, or you can give a reasonable set of predetermined options. Unless you’re using something truly weird (Zapf Chancery, anyone?), you don’t have to worry about font selection. Keep your line-height proportional.
Invert the screen
Many visitors will want light-on-dark text rather than the dark-on-light text we’ve gotten used to since the first Macintosh.
Customize colors
However, bright white on flat black will not work for everyone; it’s too bright. You can provide a few options, many of them reminiscent of 1980s-era terminals (e.g., green, yellow, or blue on black or dark brown, or the old WordPerfect 5.1 default of white on blue).
Rearrange content
This is the biggie: You have to judiciously prune your multicolumn site into one column.

If you want to be really fancy, you can make each of these options individually selectable; you might use a preferences page that lets visitors selectively enable options. (That page would pretty much have to include all the above features at once to be accessible in the first place.) But if you’re just starting out, clustering all these options as a one-click option through a single CSS file will suffice.

And a note about images: Don’t do anything special to them. Do not, above all, assume that a low-vision person won’t be interested in your photos or illustrations. We already know that low-vision kids love digicams and love shooting pictures, since the photos can then be blown up nice and big and edited on computer. If your site features thumbnails or galleries that take up a lot of horizontal space, you may need to rethink your layout. But for nearly all other sites, don’t try to hide, shrink, or enlarge your images.


We know from experience with screen-reader users that too much navigation on a page is a serious usability problem. Why else did we invent, and endlessly debate the details of, the now-infamous skip-navigation link?

Now consider the problem for a zoom user. If your navigation (whether a styled unordered list or whatever else) sits in a column at screen left, either that column will occupy a huge percentage of a magnified screen or the visitor will have horizontally scrolled to eliminate it. A large left-hand nav column is simply in the way.

The real solution is to simplify navigation so that it can be skipped if desired or just read in sequence with minimal inconvenience or confusion. I have to agree with J the Z here: If you think your site needs drop-down menus, you need to streamline your site.

To improve navigation for magnifier users:

  • In most cases, we’ll want one or at most two lines of navbar text — presented horizontally at screen top.
  • If your navigation is already simple, you may merely need to update your CSS.
  • If you’re stuck using a huge chunk of navigation, extract only the most important parts for the top navigation row. The rest can be contained at the bottom of the page, for example.

We do not have mature and well-tested ways to do this; it’s all a bit new. Worse yet, HTML stands in our way to some extent. Our options include:

  • If your navbar is marked up as a single unordered list, it may be necessary to assign classes to the items you wish to show or hide in a zoomed layout (whichever are less numerous, I suppose).
  • Another option is to use two lists, though that presumes that the precise order of entries works out fine (all the entries you want to show in a zoom layout just happen to be consecutive in one list).
  • If you have just a few items that are marked up as regular elements with divider characters between them, your navigation may be simple enough to leave as-is. If not, you can write a second navbar into your code and selectively show and hide the right navbar in different CSS files.


My esteemed colleagues Cameron Adams and Sergio Villareal wrote new zoom-layout CSS files for their sites, which you can take a look at as approximate examples of this rather new form.

Cameron Adams
The Man in Blue
Zoom layout (“contrast layout,” actually)
Sergio Villareal
Zoom layout (“high-contrast layout,” actually)
Single-column layout

This is not a lot to go on, but it’s all I could squeeze out of the many developers I polled over a period of five months.

We need further examples of zoom layouts to solidify the whole idea in the minds of visual designers. If you give this a whirl yourself on your own site, let us know in the comments to this article and, preferably, also on the ZoomLayouts page at the CSS-Discuss wiki.

Meanwhile, some existing sites use preference pages to specify type and color:

  1. K.S. Pope
  2. Confort de lecture (an offshoot of Handicapzéro)
  3. Sjoerd Visscher

Media types

So far, I have not been able to achieve consensus among potentates of the CSS Working Group that we need a new media type, zoom, to accommodate screen-magnification users. (By contrast, there was some modest agreement that a new reader property was needed. Though that proposal hasn’t gone anywhere, it still could.)

Given the constellation of display properties involved in zoom layouts, with display and hiding of specific page elements, it may be necessary to contemplate a zoom media type after all. I leave this task to others.

Similarities with small-screen rendering

As it turns out, what you’re doing when you use CSS to design a zoom layout is similar to what a handheld browser must do when confronted by a wide, multicolumn page. It too must selectively reorder and hide components so the page content can be enjoyed in a single column. The difference is that there is no significant need to radically restyle the type to make it easier to read; even the default type presentation on many handhelds is considered readable and doesn’t need to be touched.

We can compare the display formats this way:

Conventional Zoom Handheld
No single assumed audience Low-vision audience (no personal choice) PDA owner (personal choice)
Single- or multicolumn Single-column
No limits on navigation Simple navigation preferred Navigation eliminated, rewritten by proxy server, or deferred to page end
Any type color Light-on-dark preferred Browser defaults (usually dark-on-light) preferred
Any type size Large needed Browser defaults preferred

The more advanced small-screen-rendering (SSR) platforms attempt to intelligently determine which side-by-side components, images, headers, footers, and dividers of many sorts are actually important. With few sites offering valid markup, with fewer still using CSS for layout, and with no consensus at all as to how to name different components of a page, SSR devices face a serious challenge of artificial intelligence. (See references below.)

However, you as designer or developer know your own site and all its conventions. There may be a bit of trial and error in CSS properties until you produce a zoom layout that’s simple, big, and readable, but you know up front that it’s possible. And in fact, you can reuse some of the knowledge you gain in rewriting your site for zoomability to make it compatible with handhelds. Starting with your new zoomable style, make the following changes:

  1. Retain a single-column layout.
  2. Don’t specify font, size, or color (unless you really know the platforms your visitors use).
  3. Consider hiding or at least moving all your navigation. Put the content of the page first.
  4. Continue to refrain from doing anything special to images. They are a known issue in PDA browser software and you should let these user agents handle images themselves.


This article will, one hopes, serve as a starting point for a new application of CSS design principles by standards-compliant designers. It seems that, as time goes on, we discover more and more implementation details of what appear on the surface to be technologies that are frozen in time (viz. the HTML and CSS specifications). Similarly, with each passing year we learn more about how to accommodate people with disabilities gracefully without impeding the graphic design or other desirable characteristics of our sites.

But the ball is now in your court. I’d like to see quite a few more attempts at zoom layouts and, in the fullness of time, a general consensus that a professionally-designed, standards-compliant, accessible site isn’t complete without one.


Low-vision users

Helping low-vision and other users with websites that meet their needs: Is one site for all feasible? (Redish and Theofanos)
High Accessibility, High Design

Small-screen rendering

Collapse-to-Zoom: Viewing Web Pages on Small-Screen Devices by Interactively Removing Irrelevant Content
The marquee-menu methods explored in this paper — in which PDA users draw diagonal lines to collapse and expand page components — could easily be expanded to conventional browsers, as through a Firefox or Mozilla extension. (It could also be built in as standard equipment. Doing so would, incidentally, assist but not ensure compliance with Guideline 5  of the User Agent Accessibility Guidelines.)
id=“Detecting-a” title=“Full text
online”>Detecting Web-Page Structure for Adaptive
Viewing on Small-Form-Factor Devices
The authors’ method here attempts to infer structure from HTML so it can reorder page components. Needless to say, the whole thing breaks down with invalid markup: “In the page-analysis stage, HTML syntax errors left by the author could cause the HTML parser to produce [an] erroneous HTML DOM tree, which could sometimes make the high-level content-block detection produce unexpected results. For example, a pair of misplaced <form> and </form> [tags] in a web page causes our parser to place the footer of the web page under a small table in the body.”
id=“SmartView-R” title=“Microsoft Research
: Enhanced Document Viewer for
Mobile Devices
  • PDF (which Google refuses to index since it’s on an FTP site)

“Currently, far too little published material on the web is suitable for mobile devices [undesirable anyway from the standpoint of device-independence].... In a few well-defined cases, the SmartView prototype even adjusts the layout of a section by breaking it up completely and re-flowing it to fit in the window…. The layout is modified by changing the side-by-side arrangements into a top-down arrangement, because the latter is more effective on small screens.”

Opera’s Small-Screen Rendering



Many of the methods described in this article are derived from apresentation by Aries Arditi at the American Academy of Optometry convention, Dallas, 2003.12.06. The author contacted Mr. Arditi for a reference or citation to that presentation, but received no response.


49 Reader Comments

Load Comments