I know how to use “Page Up” and “Page Down” to navigate up and down a web pagedocuments. I know to use keyboard shortcuts to quickly enlarge text size or put it back to normal. I can disable your stylesheets with three key presses. I also know that if there’s no obvious link back to the home page, it’s pretty likely that the company logo will take me there.

I know these things because it’s my job. But not everybody spends every day looking at websites with an eye to how they work (or don’t work).

Escaping the mental framework which expects the users of your website to know the same things you do is difficult. On the one hand, you want to provide all these great widgets in your page which will provide this functionality: a link to the top of the page or text resizing tools. On the other hand, you know perfectly well that this functionality is already built into the browser. What’s the point of duplicating that functionality?

I go both ways. I never institute text resizing links, expecting users who need text to be resized to make use of the native functionality of their browser or to be using specialized magnifying devices. On the other hand, I always provide links which take users back to the top of the page. How do you make the choice?

In What’s the Key to Accessibility?, I wrote about providing options. In it, I emphasized striking a balance and researching your target audience — if you’re building the next Digg clone, you can probably expect your audience to know their browser pretty well. If you’re building an information resource for the grandparents of children with disabilities, on the other hand, you may want to consider making these options more obvious.

A bigger problem is when you’re building a website in a core area — one of those websites which a much broader segment of the population is likely to use. A news site, like the New York Times, for example — or a shopping site like Buy.com. Either of these are examples of sites which are large, complex, and likely to be accessed by a huge expanse of the population. You can’t make assumptions about your audience. Even in the previous examples, you can’t make any absolute assurances that your audience will know what you think they do: but you can guess with more confidence.

Five pieces of advice on Adding Functionality

  1. Don’t break native functionality. If you’re implementing something fancy, make certain that the “normal” browser functions still operate.
  2. Make it obvious. If you’re going to implement some kind of usability “special feature,” make it obvious how it works. Don’t use some kind of obscure symbol to represent the function!
  3. Don’t go overboard. If you’ve added two lines of extra navigation buttons offering every customizable feature imaginable, it’s just possible that you’ve gotten carried way. If you HAVE created this much extra stuff, don’t put it on every page!
  4. Test it thoroughly. When you’re trying to replace or supplement browser behaviors, be thorough about it. Nothing like a text resizing function that doesn’t resize the text.
  5. Track it. Attach tracking information to the controls to find out whether people actually use it. One advantage to having these kinds of tools on the page is that you can actually gather information about use — information which isn’t available from the browser tools. If you find out that nobody uses it? Goodbye!

Providing core browser functionality within a website shouldn’t be necessary. Leaving it out shouldn’t ever harm your website, as long as you’ve made certain that the native functionality of the browser continues to function. But including this functionality could be beneficial to some users, when those users aren’t aware of the functionality inherent to the tool — as long as it’s done right!