Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lint rules don't allow links with javascript:void href, or any alternative. #4141

Closed
peterbraden opened this issue Mar 11, 2018 · 21 comments · Fixed by #5330
Closed

Lint rules don't allow links with javascript:void href, or any alternative. #4141

peterbraden opened this issue Mar 11, 2018 · 21 comments · Fixed by #5330
Milestone

Comments

@peterbraden
Copy link

peterbraden commented Mar 11, 2018

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
Copy link
Contributor

Timer commented Mar 12, 2018

href={null} should work.

@Timer Timer closed this as completed Mar 12, 2018
@peterbraden
Copy link
Author

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
Copy link

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
Copy link
Contributor

Timer commented Mar 23, 2018

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

@Timer Timer reopened this Mar 23, 2018
@Timer Timer added this to the 2.0.0 milestone Mar 23, 2018
@miraage
Copy link

miraage commented Apr 6, 2018

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.

@ejose19
Copy link

ejose19 commented Apr 28, 2018

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.

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.

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

@dsteinman
Copy link

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
Copy link

abegehr commented Jul 8, 2018

bump 👍
please get rid of this rule

NickBellamy added a commit to NickBellamy/UK-Police-Station-Finder that referenced this issue Aug 5, 2018
Clicking the links in the left panel has the same effect as clicking on
the marker.

Note, this causes a warning in React:

"Links must not point to "#". Use a more descriptive href or use a
button instead  jsx-a11y/href-no-hash"

This has been raised as an issue on GitHub, and it looks as though the
developers are considering removing this warning, so for the meantime,
this code will continue to throw the warning.  For more information,
see:

facebook/create-react-app#4141
@erik-sytnyk
Copy link

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.

@Timer Timer modified the milestones: 2.0.x, 2.x, 2.0 Sep 26, 2018
@dmythro
Copy link

dmythro commented Oct 1, 2018

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
Copy link
Contributor

gaearon commented Oct 1, 2018

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
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

satya164 commented Oct 3, 2018

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

@AlmeroSteyn
Copy link
Contributor

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
Copy link
Author

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
Copy link
Contributor

AlmeroSteyn commented Oct 5, 2018

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
Copy link
Author

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
Copy link
Contributor

gaearon commented Oct 5, 2018

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

@peterbraden
Copy link
Author

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
Copy link
Contributor

gaearon commented Oct 5, 2018

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.