New rule: `anchor-ambiguous-text`

[mattxwang]

One pattern that I've occasionally caught during code review is

<a href="...">click here</a>

This is both ambiguous and often inaccessible for screenreader users (this WebAIM page on links has more). Similar issues exist for "link", "here", etc.

Do we think adding a rule to catch these errors is reasonable? I'm only familiar with this project as a user (and not a contributor), so I'm not sure if this aligns with the vision for this plugin. I also see an issue where this is more of a subjective rule (rather than a missing attribute), and would be hard to get properly without false positives. If there are other projects that are better suited for something like this, any pointers would be appreciated.

Happy to open a PR for a new rule if we think this is a good idea!

[ljharb]

Especially given that English isn't the only language people will use, and given that it's very hard to determine if these are inappropriate or not without understanding the context, I'm not sure how this would really be possible.

[mattxwang]

Especially given that English isn't the only language people will use, and given that it's very hard to determine if these are inappropriate or not without understanding the context, I'm not sure how this would really be possible.

Thanks for the quick response @ljharb! Definitely agree that both context and internationalization are concerns with a rule like this. Do you think img-redundant-alt is a blueprint for this at all? I'm not familiar with how it works in other languages (is the set of image, photo, etc. user-modifiable)?

[ljharb]

It's true that that rule has the same challenges, and yet it exists.

I'd be interested to see the results of a thorough set of tests; we would definitely want to avoid false positives.

[mattxwang]

I'd be interested to see the results of a thorough set of tests; we would definitely want to avoid false positives.

Gotcha @ljharb! What would you be looking for here? I would be happy to open a draft PR for a possible rule (and if we decide that it doesn't make sense, no harm no foul); would you want to test it against a large open-source website, etc.? Let me know what the next step should be (if there is one at all); down to contribute as much as possible!

On internationalization: could one approach be allowing the user to configure the set that the plugin compares against? That way, they could add their own set of disallowed link texts in the language(s) of their website. It's definitely not a great solution, but could be one way forward?

[ljharb]

I don't think we need to test against a website; i just mean we'd need lots of test cases to be confident we weren't causing false positives.

Before a draft PR, it'd be good to also figure out what the rule schema would look like.

[mattxwang]

Thanks @ljharb. Here's a quick draft of what I'm thinking, modeled off of img-redundant-alt:

• rule name: anchor-ambiguous-text
• behaviour: for component in the component list, if the screenreader-visible text exactly matches the disallowed list, throw a warning/error
• default (English) disallowed list: ['click here', 'here', 'link', 'a link']
• default component list: [<a>]; configurable with an option
• options:
  • component, determines which JSX elements to check
  • words, determines custom words that should be checked for
• warning message: Ambiguous text within ${component} link. Screenreader users rely on link text for context; the words ${disallowedList.join(',')} are ambiguous and do not provide enough context.

What are your thoughts?

[ljharb]

That seems reasonable. With the global components settings for link-like things, would it need a component list at all?

[mattxwang]

Sounds good! What are the next steps - should I open a draft PR now?

With the global components settings for link-like things, would it need a component list at all?

I'm not too familiar with this codebase, how does that work/where is it documented? I was basing this off of img-redundant-alt/anchor-has-content, and I'm not sure how the latter uses the global components settings (if at all). Or did you mean mapping custom elements like <Link> to an anchor? If it's the latter, I think having a configurable component list would still be useful, in the same way that the above rules have them.

[ljharb]

It's documented in the readme. The global component settings are new; added in the last minor. If it had existed prior, I suspect no rules would have their own components list.

Yes, it maps a custom element like Link to a.

[mattxwang]

I see (I was a bit confused looking at the Changelog since there's no v6.6.0 GitHub Release). I'm good to implement the rule without components as an option; I'm sure adding it later given demand would be relatively easy.

Any other comments / next steps? Or should I begin with an implementation?

[ljharb]

(oops, thanks, created a release for it)

I think a draft PR is appropriate.

[mattxwang]

FYI, I've created a draft PR #873. I have a few open questions about implementation strategy; feedback is very welcome!

[gaurav5430]

We are implementing something similar internally for our project which is specifically for jsx (as we work with react).

The skeleton of the rule that we use is:

• allow passing components array as an option . Example: ['a', 'Link', 'NavLink', 'ExternalLink']
• allow passing the array of text that should be considered invalid. Example: ['Learn more', 'Click here', 'Click to see']
• The rule checks the opening jsx element and matches that it is one of the components. If yes, it checks if the jsx children of the element are equivalent to the invalid texts.
• If they are equivalent, it then checks if there is an aria-label on the element, which might mitigate this issue, and hence does not tag it as an issue.

This rule currently is only for english, but since the user can pass the array of invalid texts, it may work alright for some i18n use cases.