feat(linter): adds jsx-a11y/no-static-element-interactions rule

[colin-harrison]

What's New

• Implementation for jsx-a11y/no-static-element-interactions - ☂️ eslint-plugin-jsx-a11y #1141
• A new crate / pnpm workspace in tasks/a11y_data
  • Extracts and transforms accessibility data from the npm registry into Rust data structures
• A new crate in oxc/oxc_aria_query
  • Home of aforementioned Rust data structures
• Util functions for parsing role attribute values

Data Needs

This rule relies on data from aria-query and axobject-query npm packages. These data are not available in any well-maintained Rust crates from my search.

There's a comment in oxc_linter/src/utils/react.rs that suggests a oxc-project/aria-query repo is a W.I.P. but that repo is labeled as "under construction" and now appears to be archived.

I found no source for axobject-query data in Rust.

I followed the lead of tasks/compat_data and crates/oxc_compat which is similarly converting data from an npm package into Rust code.

I opted to grab the minimum set of data required for this rule, but even this set should be enough to help with other unimplemented jsx-a11y plugin rules, like interactive-supports-focus, that rely on the same data.

Known Differences from ESLint Implementation

I found two main issues with the ESLint implementation of this rule.

1. There was some no-op code that seemed to imply the only expression value rules allowed by the allowExpressionValues rule were ternaries where both sides were string literals. I looked at the GH issue that led to the no-op code being added and I believe the no-op code was added due to some miscommunication. I suspect the issue reporter was using a version of the jsx-a11y plugin that didn't have the allowExpressionValues option at all. A year and a half later the ticket was picked up and that option would've existed on main and I believe the contributor assumed that the user was on the latest code so they added some new code to handle that case which the latest code already permitted. Unsurprisingly their new test case passed as the "violation" had already been permitted by the latest code.
2. There are some inconsistencies in the ESLint plugin code about how they classify role attributes. Sometimes they use the entire role attribute value to classify roles and other times they separate the string on whitespace and use the first valid role. This difference in behavior didn't seem intentional so I've made this more consistent by creating a first_valid_role() function in react.rs that uses the latter strategy.

[graphite-app]

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

• 0-merge - adds this PR to the back of the merge queue
• hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.