The attribute `{attr_name}` is not supported by the role `{r

Error message

The attribute `{attr_name}` is not supported by the role `{role}`.

What it means

This is the `jsx_a11y/role-supports-aria-props` rule in oxlint, default variant (constructor `default` at crates/oxc_linter/src/rules/jsx_a11y/role_supports_aria_props.rs:62). It fires when an element's explicit `role` does not support an `aria-*` attribute present on that element per the ARIA spec's role->supported-props table — e.g. `aria-checked` on `role="heading"`. Announcing unsupported states gives screen readers garbage or nothing.

Source

Thrown at crates/oxc_linter/src/rules/jsx_a11y/role_supports_aria_props.rs:63

    /// ```
    ///
    /// Examples of **correct** code for this rule:
    /// ```jsx
    /// <ul role="radiogroup" aria-required aria-labelledby="foo">
    ///     <li tabIndex="-1" role="radio" aria-checked="false">Rainbow Trout</li>
    ///     <li tabIndex="-1" role="radio" aria-checked="false">Brook Trout</li>
    ///     <li tabIndex="0" role="radio" aria-checked="true">Lake Trout</li>
    /// </ul>
    /// ```
    RoleSupportsAriaProps,
    jsx_a11y,
    correctness,
    version = "0.2.0",
    short_description = "Enforce that elements only contain `aria-*` properties supported by their explicit or implicit role.",
);

fn default(span: Span, attr_name: &str, role: &str) -> OxcDiagnostic {
    OxcDiagnostic::warn(format!(
        "The attribute `{attr_name}` is not supported by the role `{role}`."
    ))
    .with_help(format!("Try to remove invalid attribute `{attr_name}`."))
    .with_label(span)
}

fn is_implicit_diagnostic(span: Span, attr_name: &str, role: &str, el_name: &str) -> OxcDiagnostic {
    OxcDiagnostic::warn(format!("The attribute `{attr_name}` is not supported by the role `{role}`. This role is implicit on the element `{el_name}`."))
        .with_help(format!("Try to remove invalid attribute `{attr_name}`."))
        .with_label(span)
}

impl Rule for RoleSupportsAriaProps {
    fn run<'a>(&self, node: &AstNode<'a>, ctx: &LintContext<'a>) {
        let AstKind::JSXOpeningElement(jsx_el) = node.kind() else {
            return;
        };

View on GitHub (pinned to e1e7af627c)

Solutions

Remove the unsupported `aria-*` attribute named in the message.
If the attribute is genuinely needed, the role is wrong — pick the role that supports your state (e.g. `option` for `aria-selected`).
Use global attributes (`aria-label`, `aria-hidden`) when you only need labelling/hiding.

Example fix

// before
<h1 role="heading" aria-checked="true">Title</h1>

// after
<h1 role="heading" aria-level={1}>Title</h1>

Defensive patterns

Strategy: validation

Validate before calling

npx oxlint --jsx-a11y/role-supports-aria-props src/

Prevention

When changing a role, prune aria-* props that belonged to the old role.
Consult the ARIA role support table before adding widget state attributes.
Keep aria usage minimal: only attributes the current role supports plus globals.

When it happens

Trigger: A JSX opening element with an explicit literal `role` and at least one `aria-*` attribute that is neither in that role's supported-props list nor a global ARIA attribute. This default diagnostic is used when the role is explicitly set rather than implicit.

Common situations: Copy-pasted ARIA soup where every aria attribute is sprinkled on; changing a role without pruning its old aria props; components that forward all props including stale aria state; mixing widget attributes (`aria-checked`, `aria-selected`) onto container roles.

Related errors

AI-assisted analysis of oxc-project/oxc@e1e7af627c (2026-08-20). Data as JSON: /api/errors/10ae1410f0dd9878. Report an issue: GitHub.