Stop Linking to Nowhere

Do you find yourself writing this kind of thing in your HTML?
<a href="#" onclick="doSomething()">Some action</a>

Does that href="#" make you feel slightly uncomfortable? Like it’s not really doing anything, a bit of a hack? You’d be dead right to think that.

Links are used like this all the time and there’s really no need. The intended purpose of links is to point to another location and provide navigation. That’s why the href is there. It’s pointing to another place but it’s often left pointing nowhere.

It’s probably worth pointing out that using href="#" doesn’t actually do nothing. It adds a # onto your current location, changing the URL, so when you then click the back button it appears to do nothing but is actually going back to the last location, the URL without the #. If you do use href="#" and an onclick event be sure to use event.preventDefault() with it to prevent this location change.

Links get used in this way mainly because we want the styling and the interactivity. Hovering a link gives visual cues – underline changes, cursor changes so it’s easy for a user to see it’s something they can interact with.

So, what’s the alternative? If you’re just performing an action, use a button. It has the visual cues. It doesn’t have any hacky href="#" nonsense. It can be styled however you wish if the default styling is too full-on. It can even be styled to look exactly like a link, though personally I think there’s value in differentiating between navigation and actions.

And there’s more… You get some more benefits for free with a button.

You have a disabled property. You can easily make your action unavailable. Not so easy with a link.

It’s more touch friendly. This depends on styling but out-of-the-box it’s a larger touch target.

It has an autofocus property so it can be in focus on page load without needing any JavaScript. Ready to go at the tap of the Enter key.

If you use links for navigation and buttons for actions you get every tool doing what it’s best at. You could cut your food with the side of your fork and raise it to your mouth on the side of your knife but why would you? This isn’t really so different.

Native Browser Controls Rule

It’s become very common for designers to replace the standard native browser controls with their own custom controls. There are good reasons for this, consistent appearance across browsers and devices being the main one. However, there’s a lot more to consider than just how it looks.

Form Controls

Let’s think about something like a slider switch in place of a good old fashioned checkbox. It looks cool but…

Is it accessible?
How does it appear to a non screen user?

Does it have a disabled state?
And a read-only state?
And a focus state?
Do these states all also work for non visual users?

Can you tab to it?

Does it go back to its initial state using a form reset?

Does it work with touch gestures, e.g. swipe left to right?

Links

Now let’s think about a simple link. It’s pretty common to see icons used with an onclick event instead of links. But its not the same.

How would a user know that it’s an interactive control? Maybe it has a hover state style change but this would not help a non screen user.

A link (a tag with href attribute) does other things. You can tab to it. On Windows, you can use Ctrl + click to open in a new tab, Shift + click to open in a new window, right click and “Save link as…” (or equivalent) to download the target file. Wrapping the icon in an tag opens up a lot more possibilities.

I’m not saying don’t use your own controls but before replacing native controls think about what you might be sacrificing and make sure you’ve got it all covered.