oxc-project/oxc · warning · OxcDiagnostic

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

Error message

The attribute `{attr_name}` is not supported by the role `{role}`. This role is implicit on the element `{el_name}`.

What it means

This is the same `jsx_a11y/role-supports-aria-props` rule, implicit-role variant (constructor `is_implicit_diagnostic` at crates/oxc_linter/src/rules/jsx_a11y/role_supports_aria_props.rs:70). It fires when an `aria-*` attribute is unsupported by the element's implicit role — the role it has from its tag alone, no explicit `role` prop. The message appends the element name so you know the conflict comes from the tag itself.

Source

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

    /// </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;
        };

        let el_type = get_element_type(ctx, jsx_el);

        let role = has_jsx_prop_ignore_case(jsx_el, "role");
        let role_value = role.map_or_else(
            || get_implicit_role(jsx_el, &el_type),
            |i| get_string_literal_prop_value(i),
        );
        let is_implicit = role_value.is_some() && role.is_none();

View on GitHub (pinned to e1e7af627c)

Solutions

Remove the `aria-*` attribute that conflicts with the tag's implicit role.
Or set an explicit `role` that legitimately supports the attribute (which switches you to the default variant of this check).
If you changed the element's meaning, sweep it for leftover aria state props.

Example fix

// before
<input type="text" aria-checked="true" value={v} onChange={c} />

// after
<input type="text" value={v} onChange={c} />

Defensive patterns

Strategy: validation

Validate before calling

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

Prevention

After changing an input type or tag, sweep the element for stale aria attributes.
Do not blanket-forward aria props through wrapper components onto native tags.
Run the linter locally before pushing refactors that touch input types.

When it happens

Trigger: A JSX opening element (e.g. `<input type="text">`, implicit role `textbox`) carrying an `aria-*` attribute unsupported by that implicit role (e.g. `aria-checked`), with no explicit `role` override present; the element type is resolved via `get_element_type`.

Common situations: `aria-checked` left on an `<input>` after switching its type from checkbox to text; `aria-selected` on a `<li>`; aria props forwarded blindly by wrapper components onto native tags; refactors changing input types without cleaning attributes.

Related errors

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