It doesn’t do anything, it just sits there!

Now, normally I’m not a complete standards freak (unlike the guys working on Caja). But what does <a href="javascript:void(0)"> really mean? The answer is simple – nothing.

First of, it’s a hyperlink to a resource, which should be accessed over Javascript “protocol”. Here’s the problem – I don’t really feel that “javascript” is a protocol. And it can’t really handle resources. But lets ignore that. What is the actual resource?

The link tells “use javascript” to “retrieve”… void. Why would anyone in the world want to view void in their browser? If anyone ever wants to look at it – they’re much better off achieving that goal on YouTube…

Semantics apart – it’s not comprehensible

Lets suppose, you don’t really care about web standards and semantics. I’d probably agree with you – we’re quite far away from having a meaningful web (if ever). Still, having crap as the URL is no good – apparently, screen readers will read that URL out loud.

Can you imagine anyone discussing this over a pint: “You know, I found this great site at javascript colon void opening parenthesis zero closing parenthesis“? That kind of URL would not make any sense to regular folks.

Accessibility is NOT about screen readers, though

Such a link kills browsing experience for sighted users too. Have you ever tried what happens when you middle-click the void link? Or right-click and then select “Open in new tab”? Here – try it out (mileage may vary if you use a recent browser).

Exactly – you guessed it – nothing meaningful happens. Just as it should!

Solution 1: Use real URLs

There are several ways out of this. My favorite one is to provide a real URL. If you’re following progressive enhancement methodology in your work, you always want to provide alternative links to achieve (near full) functionality even when Javascript is disabled.

This means, that instead of having a <a href="javascript:void(0)">Delete</a> and attaching onclick handler to it, popping out a confirm dialog and then making a background call using XHR, you provide a link to e.g. /myResource?delete which brings up a form, with a real <button>.

The actual backend code doesn’t become that much trickier – you don’t really have to write up a new “delete” routine. By using a confirmation interstitial, you also provide a way to confirm the action, and you can still use a POST request, as this action has permanent effect.

Solution 2: don’t use anchor tag

The above solution doesn’t always work – if you have a really interactive application, you’re not always able to provide links. However, since you’re already using JS – why use the <a> tag where it doesn’t belong?

I did hear some advice, to use <button> for clickable things, which are not really links. You should investigate that, but anyone who has tried to style buttons, knows that it can very easily become a major pain.

Still, you can attach your onclick handlers on anything you want – div, span and so on. In such cases, you should also add tabindex to make elements focusable and make use of ARIA roles to provide guidelines on behaviour. It’s not really that hard, now, is it?

The only really painful thing here is providing :hover and :focus styles on IE6. But IE6 should also die, together with javascript:void(0).