Create-react-app: Lint rules don't allow links with javascript:void href, or any alternative.

[peterbraden]

For a variety of valid reasons, you may want to have html anchors with a href that is null for a time. One way of doing this is href='javascript:void(0)', however this triggers:
Script URL is a form of eval no-script-url" lint error.

Another way is href='#'. This triggers:
Links must not point to "#". Use a more descriptive href or use a button instead jsx-a11y/href-no-hash

Another way is <a href>, This triggers:
Warning: Received 'true' for a non-boolean attribute 'href'.

Are there ways to achieve the desired effect without lint errors, otherwise can one of these be removed?

See:

808

[Timer]

href={null} should work.

[peterbraden]

This doesn't work as it means that the href isn't passed to the dom, meaning that the style of the anchor doesn't get the link attributes.

[CloudMunk]

I'm experiencing pretty much the same as you, I get this error from my navbar links:
Use a more descriptive href or use a button instead jsx-a11y/href-no-hash

Confuses the hell outta me, but the page does display.

[Timer]

My apologies, maybe we should consider loosening this rule...

[miraage]

For a variety of valid reasons, you may want to have html anchors with a href that is null for a time

Could you please tell me these reasons? I recall using this technique in early 2000s when I was not familiar even with jQuery. Not sure if it is viable now.

[dsteinman]

Since there is no other way to make an anchor tag clickable I'd be curious why anyone would want this rule to exist, let alone be the default, and not have a way to override it.

[abegehr]

bump 👍
please get rid of this rule

[erik-sytnyk]

Would be really nice to remove that rule. Currently, in react-scripts 1.x it is not enforced, so having a big codebase it is hard to try out 2.0 version, without significate changes in your code.

[dmythro]

Yeah, for Skip to content component's link had to use eslint-disable-next-line rule (details).

Overall I'd agree to turn this rule off.

[gaearon]

I think instead of disabling this line we need to properly explain how to style buttons like links.
Just like Bootstrap does.

For example:

.ButtonLink {
  background-color: transparent;
  border: 1px solid transparent;
  cursor: pointer;
}

.ButtonLink:hover, .ButtonLink:focus {
  text-decoration: underline;
}

Then use a button:

<button className='ButtonLink'>Hello</button>

AFAIK that would correctly behave in an accessible way without hacks.

[AlmeroSteyn]

Because anchors are inline elements the style should probably also cater for this use case as well.

So I suggest:

.button-link {
  background-color: transparent;
  border: none;
  cursor: pointer;
  text-decoration: underline;
  display: inline;
  margin: 0;
  padding: 0;
}

  .button-link:hover,
  .button-link:focus {
    text-decoration: none;
  }

Now the button can be used inline in text as one can with anchors.

I also inverted how the underline works from that of Bootstrap to display as links by default with the underline removed on hover. However the other option can just as easily be done.

[alfonsomartinde]

To get what @peterbraden asked, I just write "#/" as href value:

<a href="#/">...</a>

The warning is gone, and the output HTML is valid.

[satya164]

It's still incorrect use of an anchor tag. Why not use button?

[AlmeroSteyn]

Maybe some clarification is in order as to why this rule exists and why it is a good idea to follow it instead of finding ways to go around it.

I currently have a PR open that will make the error message clearer and also show where to find more information. The current docs for that can be found here https://github.com/evcohen/eslint-plugin-jsx-a11y/blob/master/docs/rules/anchor-is-valid.md. It contains an explanation of why this rule exists.

But to expand on it, abusing an anchor tag for anything but navigation goes way beyond being contrary to the specification of this element. It causes a very real detrimental experience to many users out there when confronted with this situation.

Here I am referring to any user that uses a keyboard to navigate the internet. That includes users who rely on screen reader software to use the web. Exact statistics are hard to find due to the privacy impact it would have, but one study shows that the number of users likely to use a keyboard alone just due to a disability being about 7% of the working adults in the UK, US and Canada. https://www.powermapper.com/blog/website-accessibility-disability-statistics/

This does not even include those who choose to use a keyboard or sustained a temporary disability like a broken arm etc.

The point is we are talking about millions and millions of people.

If an anchor has no href it does not act a link. It becomes, what the spec calls, a placeholder. In fact you are unable to select and activate it using a keyboard alone. Regardless of whether it contains an onClick handler or not. If this element is important to the function of the application it means that the application would block around 7% or more of the population from using this application at all.

If the anchor container a dummy href you will be able to interact with it using the keyboard, however the interaction will be unexpected. Screen reader users have the elements announced to them, so, if you come across a link it says "Link", regardless of how it is styled. And links are expected to navigate. It is extremely confusing to a screen reader user when they encounter a link, activate it and no navigation happens.

By using the fix @gaearon suggests above and turning it into a button, EVERYONE can interact with it. All keyboard users can interact with it while screen reader users hear "Button" and expect it to perform an action and not a navigation. All that, without having to hack the href or suppress the rule.

The rule is not there to be an irritation but to try and assist us in making applications that can be used by the widest group of users possible :-)

[peterbraden]

I'm aware of the rationale. In fact the desire to keep semantic navigation elements as anchors rather than use a button was the entire reason I didn't just add an onClick to a different element.

[AlmeroSteyn]

Thank you for responding.

Semantic navigation elements are very important indeed. But the reason I thought to add some information is that the browser implementation of the <a> element differs when it has an href to when it doesn't.

Without an href the element does not accept keyboard focus. So a user using, for example, the NVDA screen reader would completely miss the element if navigating a page in focus mode. The user would need to know to switch to browse mode in the screen reader and go and hunt for the element to interact with it. And whether or not the user would even be able to interact with it would depend on which screen reader and which browser they use.

For sighted keyboard-only users there would be absolutely no way to interact with the element, even if it has an onClick handler as you cannot Tab to it.

So the discussion is not about the semantics of the element itself, but if people can even use it at all. By giving it an onClick handler and a null href value and then styling it the same as all other <a> elements creates situations that will completely block a large number of users.

So the suggestion would be:

1. If the element needs no onClick handler and has no href, rather use a span.
2. If it needs an onClick handler and has no href, rather use a button and style it as a link if that is required. It is perfectly best practice to do a navigation as the result of an action performed by a button.
3. If the element is in fact a navigation element then it can simply get a good href.

[peterbraden]

To clarify, the situation that I initially had, which differs from other peoples cases here, was an anchor that had a null href for a time, but never had an onClick. It was a pure navigational element that needed a null href while some async logic happened.

But this was months ago, I found a workaround, I no longer really care about this ticket. Strong lint rules are annoying when you have an edge-case, such as mine.

[gaearon]

You can always // eslint-disable-next-line for an edge case.

[peterbraden]

You can eslint disable, you can use one of the many hacks in this thread, you can give up and use a span, or you can eject and change the lint rules. Many options, each requiring cognitive load, for what ultimately is unimportant.

Life is short, I'm assuming this is WONTFIX. Closing the issue to save my inbox.

[gaearon]

You can also unsubscribe :-) I'd feel better about closing after https://github.com/evcohen/eslint-plugin-jsx-a11y/pull/486 gets out and we update our lint message to be more specific and useful. But either is fine.