Introduce a new rule to flag Link in text blocks without inline

[khiga8]

Relates to:

• Create a lint rule to encourage inline prop for <Link>s in text block #182
• https://github.com/github/accessibility/issues/6434

What

This PR introduces a new accessibility lint rule to ensure that links inside of a text block have the inline prop.

Why

The current recommendation in dotcom is to add inline prop on all Links that appear within a text block to ensure that a user’s accessibility link underline setting is respected.

However, there are currently no automated tools to enforce that developers actually set this prop on their links. As a result, developers continue to add Links to text blocks contributing to 1.4.1: Use of Color accessibility issues.

By having this lint rule in place, we can proactively surface to developers when they should set the inline prop.

Implementation details

The logic essentially treats any Link that appears with a string literal on either side of it as a link within a text block. It checks for the presence of inline or inline={true}.

For example, the following will be flagged:

<p>
  Learn more about <Link href={...}>GitHub</Link>.
</p>

<SomeComponent>
  <Link href={...}>GitHub</Link> is where you share code.
</SomeComponent>

In addition, this lint rule aims to minimize false positives and will skip Links even if adjacent text is detected for the following scenarios:

• <Link sx={{fontWeight:...}}> or <Link sx={{fontFamily:...}}> - these technically may provide sufficient distinguishing styling.
• <Link> where the only adjacent text is a period - these can't really be considered a text block.
• <Link> where the children is a JSX component, rather than a string literal - this is because the JSX component may be an icon link, in which case it may be sufficient to distinguish.
• <Link> that are nested inside of headings - these feel safer to skip...

Testing / Validation

I've tested this branch against dotcom to make sure there's nothing unexpected! This flagged around 140 Link missing inline in dotcom. I've gone ahead and opened fixes for whatever was flagged by this rule across 8 PRs.

I broke this up into reviewable chunks so that codeowners can make sure to minimize false positives raised by this rule. (Related: https://github.com/github/accessibility/issues/6434)

Reviewers 📣

1. I am open to any feedback on this logic! Is there anything I'm missing?
2. Is it okay to enable this rule in recommended.js or is this only relevant to dotcom?
3. Right now this rule will flag <Link underline> even though technically underline does provide sufficient styling. I decided to flag underline because I noticed it is deprecated so maybe this is an opportunity for consumers to migrate to inline. Let me know if you think we shouldn't flag underline!

[changeset-bot]

🦋 Changeset detected

Latest commit: 5a27eea

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
eslint-plugin-primer-react	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[khiga8]

I'm still in the process of getting feedback to make sure there's nothing unexpected with the instances flagged by this rule via PRs in dotcom but want to open this up for early review!

[siddharthkp]

Makes sense to me on a theoretical level, hard to review without testing it. Can we run this once on gh/gh to see if it catches any false positives?

Update: Just saw you are already doing that ❤️

[khiga8]

All PRs in dotcom have been reviewed and merged without any issues!
This is ready for a formal review! :D

[khiga8]

Given that inline is specific to dotcom's setup, maybe this should not be turned on by default. would love to hear what others think!

[siddharthkp]

True, we shouldn't turn it on by default

[siddharthkp]

LGTM!