Within-Page Links for AJAX, "Return to Top", Skip-Links

(Sidebar to Jakob Nielsen's column "Avoid Within-Page Links.")

I received several reader comments on my recommendation to avoid within-page links.

AJAX-style Within-Page Refreshs

Ole Begemann writes:

While I agree with your assessment, I wonder how AJAX fits into this. AJAX is all about interactivity within the same page. Do you think this does more harm than good because of the confusion it causes (and e.g. the Back button does not work as expected anymore)? Or should AJAX actions be invoked by buttons rather than links?

Jakob's answer:
Interactivity (i.e., features) and navigation are different. So it should be OK to have things happen within the same page as long as they are not seen by users as representing a movement to a new location.

See this screenshot for an example:

Screenshot from Yahoo showing stock price curve over three months, with links to change the view to one day, five days, one year, two years, five years, and the maximum time range.
Screenshot of the price of a stock over three months from Yahoo! Finance.

This is a stock chart showing the price of Amazon.com's stock over three months. Click the link marked "1y" to get the price over a year instead. It so happens that the implementation is a link to a new page, instead of a within-page refresh-in-place, but there's no reason for that, except for the benefit I get from being able to easily copy the URL and link to it in the caption. Anyway, if Yahoo had used a button instead of a link to change the view of that chart, it should have worked well as a within-page refresh.

Most likely it should be a guideline to use a different UI widget than a plain-text link for this purpose. For sure, we know that it's a guideline to use buttons for commands and links for navigation, and changing the view of a chart seems more like a command than it seems like navigation. An alternative, in the example in the screenshot, would be to use tabs to alternate between the views. This would certainly comply with the standard use of tabs in applications, even though there would be a conflict with the way tabs have often been abused on websites (which often use tabs to denote navigation instead of alternate views).

For switching between alternate views of the same data, it's actually better if the Back button doesn't work, because it would mainly be used when the user wanted to return to the previous location (say, the list of stocks they're tracking), not if they want to see the previous data view again.

The operative question is whether the user's action feels more like a manipulation of the same data or a movement to some new data. If the former, then it's a command. If the latter, it's navigation. To really find out, you need to observe users and perform a task analysis, but often you can come up with a good first guess and use for your initial design before it goes to testing.

"Return to Top" Links

Vincent Simard writes:

Should "Return to top" links be avoided? They seem accepted by a lot of developers and users although I have not tested them vs. users scrolling back to the top of a page manually.

Jakob's answer:
Yes, "return to top" can be avoided, because the exact same functionality is provided by simply dragging the scrollbar to the top of the page. It's almost always better to rely on a single, generic interaction technique so that users don't have to ponder the choice between two alternate interaction techniques for the same goal. The time it takes to make the decision is usually more than the time saved by the shortcut.

(The exception would be for extremely long pages that would take forever to scroll, but such pages should be avoided in the first place.)

Horizontal Scrolling

J. D. A. Wiseman writes:

Internal links are not only for long lists: also wide maps that cannot be less wide. For example, http://www.jdawiseman.com/papers/games/jsw2/jsw2-central.html#the-chapel
Awkward, but in the context unavoidable.

Jakob's answer:
Of course, in general, there's a guideline to avoid horizontal scrolling, but a wide map would be one of the exceptions. For a low-tech solution, within-page links may be an acceptable way to jump to a specific part of this type of map. A more fancy solution would be to have a special map controller, but that would be overkill for a simple site like yours.

Skip Links for Users With Disabilities

Mike Elledge writes:

I would suggest another situation where skip links are both a benefit and meet user expectations:
When used to skip navigation (or, alternatively, go to content) for persons using adaptive technology.
This is commonly recommended by persons within the accessibility community to enable AT users to avoid unnecessary tabbing, reducing fatigue and repetition. Screen readers, such as JAWS, identify such links as "in-page" so that users are further informed.

Jakob's answer:
This is a good point, and may be one of the few cases where the user experience is better for users with disabilities than for non-disabled users. In general, our testing has found that blind and low-vision users suffer three times as bad usability problems as sighted users, so it's only fair that they get one thing in their favor. When you use a browser that gives special (and appropriate) treatment to within-page links, then they can certainly be helpful.

The most common use of "skip links" is a link on the top of the page that moves users directly to the content area of the page, thus bypassing the extensive amount of crud in the form of navigation bars and other utility information. Sighted readers almost always skip this information initially, simply by looking in the content area first. Non-sighted users sometimes (but not always) like to start with the content as well, and skip-links is one way to give them this choice.

A skip-link is usually made invisible to sighted users, and thus it won't bother people with traditional, visual browsers.

In the long run, I believe that a better solution would be to have a semantic encoding that would denote different parts of a page as content vs. navigation and include a dedicated command in screen reader software for switching between the two. These two different areas of a page need to be accessed in different task modes, and it's almost as common to need to move from content to navigation as the other way around.

Some specialists in technical accessibility (which is a different discipline than usability for users with disabilities) suggest an alternative: place the content first and the navigation second in the file and then use CSS to reverse this order for sighted users. This is not a good idea:

Many low-vision users alternate between visual and auditory modes of access, so they would be hurt by an inconsistent placement of the two types of information across their two browsers.
As just stated, users also need a way of skipping from the content to the navigation, and if the navigation options are at the end of the page, you will sometimes force people to wade through masses of content that they don't want, just so that they can get to the links to other pages.
Blind users form mental models of websites, just as sighted users do. Blind users obey Jakob's Law, just as sighted users do ("users spend most of their time on other sites") Therefore, blind users have strong expectations for the structure of a website when they first arrive, and these expectations include the convention that the navigation comes first. Swapping the order of navigation and content will confuse many blind users.

> Other Alertbox columns (complete list)
> Sign up for newsletter that will notify you of new Alertboxes