How to Disable Links
A disabled link is not a link, it’s just text. You need to rethink your design if it calls for disabling a link. Bootstrap has examples of applying the .disabled class to anchor tags, and I hate them for it. At least they mention that the class only provides a disabled style, but this is misleading. You need to do more than just make a link look disabled if you really want to disable it.
Surefire way: remove the href
If you have decided that you are going to ignore my warning and proceed with disabling a link, then removing the href attribute is the best way I know how. Straight from the official Hyperlink spec:
The href attribute on a and area elements is not required; when those elements do not have href attributes they do not create hyperlinks.
This attribute may be omitted (as of HTML5) to create a placeholder link. A placeholder link resembles a traditional hyperlink, but does not lead anywhere.
/* * Use your preferred method of targeting a link * * document.getElementById('MyLink'); * document.querySelector('.link-class'); * document.querySelector('[href="https://unfetteredthoughts.net"]'); */ // "Disable" link by removing the href property link.href = ''; // Enable link by setting the href property link.href = 'https://unfetteredthoughts.net';That’s not enough, I want something more complex so that I can look smarter!
If you just absolutely have to over-engineer some extreme solution, here are some things to consider. Hopefully, you will take heed and recognize that what I am about to show you is not worth the effort. First, we need to style our link so that it looks disabled.
Setting color to currentColor should reset the font color back to your normal, non-link text color. I am also setting the mouse cursor to not-allowed to display a nice indicator on hover that the normal action is not allowed. Already, we have left out non-mouse users that can’t hover, mainly touch and keyboard, so they won’t get this indication. Next the opacity is cut to half. According to WCAG, disabled elements do not need to meet color contrast guidelines. I think this is very risky since it’s basically plain text at this point, and dropping the opacity in half would make it very hard to read for users with low-vision, another reason I hate this. Lastly, the text decoration underline is removed as this is usually the best indicator something is a link. Now this looks like a disabled link! But it’s not really disabled! A user can still click/tap on this link. I hear you screaming about pointer-events .
Ok, we are done! Disabled link accomplished! Except, it’s only really disabled for mouse users clicking and touch users tapping. What about browsers that don’t support pointer-events ? According to caniuse, this is not supported for Opera Mini and IE pointer-events unless display is set to block or inline-block . Also, setting pointer-events to none overwrites our nice not-allowed cursor, so now mouse users will not get that additional visual indication that the link is disabled. This is already starting to fall apart. Now we have to change our markup and CSS…
Wrapping the link in a < span >and adding the isDisabled class gives us half of our disabled visual style. A nice side-affect here is that the disabled class is now generic and can be used on other elements, like buttons and form elements. The actual anchor tag now has the pointer-events and text-decoration set to none . What about keyboard users? Keyboard users will use the ENTER key to activate links. pointer-events are only for pointers, there is no keyboard-events. We also need to prevent activation for older browsers that don’t support pointer-events . Now we have to introduce some JavaScript.
// After using preferred method to target link link.addEventListener('click', function (event) < if (this.parentElement.classList.contains('isDisabled')) < event.preventDefault(); >>);Now our link looks disabled and does not respond to activation via clicks, taps, and the ENTER key. But we are still not done! Screen reader users have no way of knowing that this link is disabled. We need to describe this link as being disabled. The disabled attribute is not valid on links, but we can use aria-disabled=»true» .
Now I am going to take this opportunity to style the link based on the aria-disabled attribute. I like using ARIA attributes as hooks for CSS because having improperly styled elements is an indicator that important accessibility is missing.
.isDisabled < cursor: not-allowed; opacity: 0.5; >a[aria-disabled="true"] < color: currentColor; display: inline-block; /* For IE11/ MS Edge bug */ pointer-events: none; text-decoration: none; >Now our links look disabled, act disabled, and are described as disabled. Unfortunately, even though the link is described as disabled, some screen readers (JAWS) will still announce this as clickable. It does that for any element that has a click listener. This is because of developer tendency to make non-interactive elements like div and span as pseudo-interactive elements with a simple listener. Nothing we can do about that here. Everything we have done to remove any indication that this is a link is foiled by the assistive technology we were trying to fool, ironically because we have tried to fool it before. But what if we moved the listener to the body?
document.body.addEventListener('click', function (event) < // filter out clicks on any other elements if (event.target.nodeName == 'A' && event.target.getAttribute('aria-disabled') == 'true') < event.preventDefault(); >>);Are we done? Well, not really. At some point we will need to enable these links so we need to add additional code that will toggle this state/behavior.
function disableLink(link) < // 1. Add isDisabled class to parent span link.parentElement.classList.add('isDisabled'); // 2. Store href so we can add it later link.setAttribute('data-href', link.href); // 3. Remove href link.href = ''; // 4. Set aria-disabled to 'true' link.setAttribute('aria-disabled', 'true'); >function enableLink(link) < // 1. Remove 'isDisabled' class from parent span link.parentElement.classList.remove('isDisabled'); // 2. Set href link.href = link.getAttribute('data-href'); // 3. Remove 'aria-disabled', better than setting to false link.removeAttribute('aria-disabled'); >That’s it. We now have a disabled link that is visually, functionally, and semantically disabled for all users. It only took 10 lines of CSS, 15 lines of JavaScript (including 1 listener on the body), and 2 HTML elements. Seriously folks, just don’t do it.
Link element load event support for CSS Style Sheet includes, finally!
In the long history of developer attempts at creating a method of loading CSS Style Sheets via LINK tags with load event support, there has been a lot of FAIL and almost no WINNING! Oddly enough, Internet Explorer has supported a load event on LINK tags for as long as I can remember, but Firefox and the Webkit bunch…not so much.
What are people doing currently to service this need? Well here’s an example of half-baked solutions that have surfaced over the last couple of years on Stack Overflow (I have added my solution to the list, so up-vote it!). Most developer have been reduced to loops that look for the new sheet in the StyleSheet object at short intervals or even loading the link tag in an iframe and using the frame’s onload event, two methods that cause me to puke on my shoes on principle.
The Solution
Well web devs, today is the day. Yup, CSS Style Sheet loading via LINK tags with pretty damn legit load event support is a reality:
var loadCSS = function(url, callback) < var link = document.createElement('link'); link.type = 'text/css'; link.rel = 'stylesheet'; link.href = url; document.getElementsByTagName('head')[0].appendChild(link); var img = document.createElement('img'); img.onerror = function()< if(callback) callback(link); >img.src = url; > The code above creates a LINK tag for your CSS file and inject it into the head of the document, there’s certainly nothing odd about that. Next comes the interesting part, it creates an IMG tag and adds your CSS file location as src parameter of the element then injects it into the page. The browser parser downloads the file and attempts to parse it, which predictably fails as it is the wrong MIME type. That failure triggers the error event on the image element. We know the file is present at that point, so the load event you pass to the function is fired from inside the image element error event, the image element is then deleted from the document. Whether cached or not, this method will fire your load event for any CSS file you include, when the file is in the cache it is called immediately — which is a huge benefit.
Try it out!
Here it is a live demo, I have added an alert as the load event default for example sake:
Links with Inline SVG, Staying on Target with Events
It’s pretty common to use SVG within an anchor link or otherwise “click/tappable thing” on a web page. It’s also increasingly common that the SVG is inline
$("a").on("click", function(event) < // `this` will always be the console.log($(this).data("data")); // "something" >);That will work perfectly fine. Note there is a data-* attribute on the anchor link. That’s probably there specifically for JavaScript to access and use. No problem at all how we have it written right now, because within the anonymous function we have bound, this will always be that anchor link, which has that attribute available. Even if you use event delegation and call some function who-knows-where to handle it, this will be that anchor link and you can easily snag that data-* attribute. But let’s say you’re going to rock some raw JavaScript event delegation:
document.addEventListener('click', doThing); function doThing(event) < // test for an element match here >You might just have to check the tagName of the element that was clicked, and if you know it was a sub-element, move up the chain:
document.addEventListener('click', doThing); function doThing(event) < var el; // we can check the tag type, and if it's not the , move up. if (event.target.tagType == "rect") < // move up TWICE el = event.target.parentElement.parentElement; >else if (event.target.tagType == "svg") < // move up ONCE el = event.target.parentElement; >else < el = event.target; >console.log(el.getAttribute("data-data")); >That’s pretty nuts though. It’s too tied to the HTML and SVG structure. Toss a in there around some s, which is a perfectly fine thing to do for grouping, and it breaks. Or the tagType is path not a rect , or any other DOM difference.
Personally I’ve been preferring some CSS solutions.
One way is to lay a pseudo element over top the entire anchor element, so that the clicks are guaranteed to be on the anchor element itself, nothing inside it:
This seems to work pretty well too:
pointer-events typically doesn’t work in IE (it does in 11+, but not lower), but it actually does when applied to SVG, in IE 9+, which is the version of IE that supports SVG anyway.
Here’s a Pen with the issue demonstrated and the fixes:
See the Pen owyFj by Chris Coyier (@chriscoyier) on CodePen.
If you’re using SVG in a click target, be very careful you’re getting the right element in JavaScript, and if you have trouble, consider a CSS cover.