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

href={null} should work.

bump 👍 please get rid of this rule

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

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

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

My apologies, maybe we should consider loosening this rule…

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 😃

I use href='# ’ (notice the space after #) which retains the css of a tag and doesn’t alter the URL in any other way a normal # would do.

Just for visually design purposes when the route to that specific is either not defined or not implemented. I’d rather use the href attribute than add a class to use cursor: pointer

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.

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

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.

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.

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.