Who framed the web: Frames and usability

Back in the nineties, using frames to split a browser window into several independent parts was very popular. Much due to the increased awareness of usability and accessibility over the last few years, frames usage is not quite as widespread as it used to be. However, frames can still be found on many sites, especially those that haven’t had a major overhaul in a while.

If you spend most of your online time reading blogs, you hardly ever come across any sites that use frames. That’s good, considering that blogs are typically very rich on information. I don’t miss frames at all, and it’s been years since I last used frames myself, but recently I asked myself what the problems with frames are, and if there are occasions where the pros of frames outweigh the cons.

The problems with frames

The drawbacks are obvious to some, while others think frames have some things going for them. The problems I see with frames are mostly related to usability and accessibility. You may have heard of the problems before, but let me reiterate:

Frames break the unified model of the web. One of the basic principles of the web is that every page is represented by a unique URL—the page is the atomic unit of information. Frames break this fundamental principle.
Frames cause problems for search engine robots. While it is possible to provide workarounds that allow search engine robots to crawl a frame based website, those workarounds are still workarounds. There will also be problems for visitors that come to a framed site from a search engine. Those visitors are likely to land on documents that are incomplete when viewed outside of the context of the frameset they belong to. Crucial elements like navigational links may be missing, for example.

Some frame-dependant websites try to get around these problems by using the file robots.txt to tell search engines not to index sub pages. On other sites, JavaScript is used to prevent visitors from viewing any document outside of its parent frameset. Both of these methods—preventing deep-linking and disallowing search engines from indexing a site—may work, if the goal is to get fewer visitors.
Frames make URLs stop working. If a visitor wants to send someone the URL of a document within a frame based site, they can’t just copy the address from the browser’s navigation or location field. That’s the frameset’s URL, not that of the current document. It’s possible to extract the URL to a document within a frameset, but many people don’t know how to do that. Even if you do manage to find the document’s URL, it leads to an incomplete page, creating the same problem as when a search engine indexes a frame based site.
Frames break bookmarking. Most web browsers can’t bookmark a page inside a frame based website. When you open the bookmark, you will go to the default state of the frameset, which is usually the website’s homepage, and most probably not the page you intended to bookmark.
Frames make printing more difficult. Many visitors will have problems when trying to print documents. It’s common for browsers to require that you activate a frame by clicking in it (or tabbing to it) before you can print it.
Frames hurt accessibility. While the leading screen readers can handle frames, a frame based site is more complex, and thus more difficult to navigate in a non-graphical browser. For this reason, accessibility guidelines advise against using frames.
Frames increase technical complexity. Besides causing trouble for the site’s visitors, developers using frames make things harder on themselves. A frame based website is technically more complex, and more time consuming to develop and maintain than a site that doesn’t use frames. For example, something as simple as keeping the navigation system in sync with what’s being displayed in the main content area can get really complicated.

Iframes

What about iframes (inline frames) then? Well, usability-wise they really aren’t all that different from normal frames. They suffer from most of the problems mentioned for normal frames. Iframes are probably slightly less complex to maintain than normal frames since they don’t need special frameset files.

There are also reports of potential accessibility problems with iframes, where under some circumstances an iframe grabs focus when its content has finished loading. This can be very confusing for someone using a screen reader, and can cause unexpected results when printing. I haven’t seen this occur in my (limited) testing, but it’s something to keep an eye on.

CSS based frame imitations

CSS can be used to imitate the look of frames. This will avoid most of the problems with real frames. However, it can also cause usability problems that are different from those caused by frames.

One CSS technique used for this displays a header and a footer in fixed positions, letting the whole browser window scroll when necessary. The main content area will then slide behind the header and footer. I’m not aware of this technique causing any serious problems.

However, when an inline frame is imitated by using the CSS declaration overflow: auto, printing the full contents of the “frame” becomes impossible in the browsers I have tested—only the visible part is printed. This can be circumvented by providing a print style sheet, but it’s something that you should be aware of.

Another problem with the overflow: auto technique is that in many browsers, scroll-wheel mice cannot be used to scroll the contents of a “CSS frame”. While this is not a huge problem for most, and probably something that should be fixed by browser vendors (Apple and the Mozilla Foundation come to mind), it is very annoying.

Frame imitations cause fewer problems than real frames, but you should be aware that there are issues. Those issues can be avoided by providing alternative style sheets, both for viewing and printing.

Frames and frame imitations aren’t always bad

You can probably tell by now that I am no fan of frames, iframes, or frame imitations. They do have their uses though. Frames can be useful for intranets as well as for applications like web based e-mail and content management systems, where most of the problems noted here are of little or no concern. On a public website, however, they cause too many problems and should be avoided.

Visual arguments for using frames

But if frames are so bad, why do they even exist? Well, because they were invented back in the nineties, when every new browser feature had to be used just because it was possible. The question should probably be “Why does anyone use frames on public, information based websites?”.

In my experience, most of the web professionals that like to use frames are more visual design oriented than structure oriented. I don’t know if that assumption is true, or if it’s just coincidence. What I do know is that I’ve had plenty of clashes over frames with visually oriented designers wanting to confine a site’s content to a tiny scrollable area. Their reason for wanting to do this is usually a desire to keep the site’s navigation and/or “branding” always visible. Usability, accessibility, and search engine visibility are not on their radar.

I don’t mean that as a knock against all visual designers—I’m just bringing it up as an example of the attitude I’ve run into over and over, especially when working with designers coming from a print background.

Conclusions

To me there is no doubt that frames should be avoided for public websites. They just cause too many problems. For web based applications and intranets however, many of the problems mentioned are of less concern, so there are cases where frames can be useful. Think carefully before using frames though—ask yourself whether you really need them or if there is a better solution available.

As for CSS based frame imitations, my feeling is that those techniques can be useful, but should be used with care. Be aware of the printing problems they can cause, and don’t squeeze your content into a tiny, scrollable area just because you can. Remember that for most sites, people don’t visit just to admire the pretty design—they come looking for content.

Posted on November 18, 2004 in Usability, Search Engine Optimisation, Accessibility