Some pointers on default cursors

Every so often in a project, the issue comes up of whether cursors on buttons should be ‘the hand’ or default. The spec says they should be default, but many people (myself included, until recently), are unaware. Many designers I’ve worked with want pointer-cursors regardless of what the spec says.

This is the thing: links (<a/>) go to somewhere else, buttons ( <button> s) let users perform actions. The ‘hand’ indicates to a user that their cursor is on a link, which will take them somewhere. And can do so in another tab, copy/paste the link, drag it to another window, et cetera. Other interactive elements on the page (buttons, for example) just get a default cursor. TL;DR: the hand does not mean clickable.

What the standards say

The above is not my personal opinion, it is what the CSS spec says and what all browsers do by default. You can see this when you hover buttons in your OS, or look at the browser buttons to switch tabs. Or on the ‘Search’ button of Google dot com.

Apple’s OS X Human Interface Guidelines also say the ‘hand’ means the content is a URL link.

Microsoft’s guidelines are clear, too:

To avoid confusion, it is imperative not to use the hand pointer for other purposes. For example, command buttons already have a strong affordance, so they don’t need a hand pointer. The hand pointer must mean “this target is a link” and nothing else. (Emphasis theirs)

If we manually add a hand cursor to a button, we suggest to a user that they will be taken elsewhere, while they won’t. We would be breaking an affordance that was put into the web. It’s like taping a sticker that says ”Push me” over a well designed door handle (see also: Don Norman).

Clearly, standards say the hand is just for links. And there’s a great argument to be made to not mess with browser defaults.

Using ‘the hand’ anyway

Many people apply a pointer cursor to their buttons anyway. I have done so, too. I’ve heard many say they add the pointer to improve usability. In addition, Bootstrap and various other CSS frameworks also apply pointer cursors to their button (note that Normalize used to, but recently removed them).

Whether we just did not know about the standard way, or purposefully ignored it to improve things for our users, ‘the hand’ on buttons is somewhat becoming a de facto standard. It is done all over the place, so some users may now expect hand cursors on buttons.

Basically, I think there are now two standards.

There is a further complication: in practice, there is a grey area between buttons and links.

• A “Back to top” link is literally a link to the top of the page, but, especially when it animates the user back to the top, it feels like it performs an action, too.
• In a tabs component I recently built, each tab is marked up as a link to an area in the page. Visually, clicking it, ‘opens’ a tab. That’s an action, right? But what if you use a modifier key and open it in a new tab? That would also still work.
• How about a button that says “Log in”. Sounds like an action, but what if the button is a link and just takes the user to a page where they can login?
• What about a button in a <form method="POST" />? You can submit in a new tab, which makes it a bit like a link, but it also submits data, which makes it more like a button that performs an action. Or a form with GET, which should have no side effects at all?

I find that in team discussions, we talk about something being a ‘button’, yet in my HTML, I use the <a /> . Or even the other way around, occasionally.

Conclusion

The question is, does apply the ‘wrong’ cursor really matter? When I asked around on Twitter, some said applying hand cursors wrongly is a non-issue, as it confuses no one and it’s non-hand cursors that cause usability issues.

However much I think existing standards are the best to follow, I guess we have pretty much reached a situation where there are two standards, and either one is okay to use. Especially since things on the modern web are often not clearly a link or a button. Striving for consistency, at least within the same website, is probably the best thing we can do for your users.