Question

A third party script is being used on a site I work on that replaces a few instances of <a href=""> with <a>. The links still work thanks to another part of the script, but they are no longer treated as links by user agents.

I can restore them to the tabbed navigation order by adding tabindex="0" but how can I make assistive technologies announce them as links or include them in a list of all links on a page?

Would adding role="link" help at all?

I am pushing the third party to improve their script so that the href is left intact. But in the meantime how do I best repair the damage that’s being done?

I can’t add either the original href or something like href="#" back to the links as the third party code will no longer do what it does. I hope that they improve their code so that I can, but for now I need to make the link accessible without the ‘href’.

Answer 1

To make a non-href <a> behave like an <a> (and be accessible), you’d have to add role=link, tabindex=0, style it to look like a real link, and add keyboard handler code to treat Return as a click.

role="link" isn’t sufficient; a screenreader may report it as a link, but without tabindex="0" and appropriate visual styles, a sighted user won’t be able to tab to it in the first place, and without a keyboard event handler, only mouse users will be able to click it. (Technically screenreader users typically have hotkeys to simulate a mouse click, but keyboard-only sighted users generally don’t have that option, so don’t rely on it.)

Alternatively, if (big if!) the crazy script you’re using allows for it, you could try shimming a ‘keyboard click source’ (my terminology) <a> just inside the original one: so where you have:

<a>foo</a>

you replace it with:

<a><a class='shim' href="javascript:void(0)">foo</a></a>

(The class='shim' is only needed if you need to do the event stuff described later…)
You can do this in jQuery using something like: (borrowing from Jack’s answer)

$("a:not([href])").wrapInner("<a class='shim' href='javascript:void(0)'></a>")

How this works is that the inner newly-added <a ...> has a href, so it is exposed as a link and is tabbable. More importantly, if a user tabs to it and presses return, the default A behavior converts that keyboard input into a click event. This specific A has a href that returns undefined/void(0), so no actual navigation happens, but the click event will still bubble up to the original A, which gets to act on it.

(This is a neat pattern for allowing some parent element – often a DIV or similar – to handle click events, adding a child tabbable A that can source click events from keyboard gives you UI that’s both mouse and keyboard usable.)

The big caveat here is that it assumes that your original script doesn’t care about the target of the event. If that script does check this, it will get confused when it sees click events coming from the shim A’s rather than the original As. One way to get around this is to capture and re-raise the event, which can be fiddly, and may only work on recent browsers – eg using something like:

// 'shim' class used so we can do this:
$("a.shim").click(function(e) {
    e.preventDefault();
    e.stopPropagation();

    // the following works if listener using jQuery or is setting onclick directly, otherwise...
    // $(e.target).parent().click();.

    // More general way to raise events; may need alternate for IE<9
    var e2 = document.createEvent("UIEvents");
    e2.initUIEvent("click", true, true, window, 1);
    e.target.parentNode.dispatchEvent(e2)
});