In one paragraph
ARIA attributes must conform to valid names means the rule encountered an aria-prefixed attribute outside its recognised vocabulary. Identify the intended meaning before correcting or removing it. Role is not an aria-role attribute, and application-specific data should not invent ARIA names. A recognised spelling still needs a valid value, permitted role context, and working behaviour.
Why it matters
ARIA attributes communicate defined semantics to supporting user agents. A plausible-looking custom name does not acquire accessibility meaning because it begins with aria-. A typo in a labelling relationship can leave a control without the name the developer thought was present.
A browser may retain an unknown attribute in the DOM, and scripts or CSS may still read it. That is different from exposing the intended standard accessibility semantics. Avoid claiming such attributes disappear entirely from every consumer.
Vocabularies evolve and implementations can lag or anticipate published specifications. New draft features should not be treated as universally supported because one engine recognises them, nor should a legitimate feature be deleted blindly because an older checker flags it.
How WebAuditOS evaluates this finding
The supplied aria-valid-attr rule compares applicable rendered aria-prefixed names with its version-specific known set. Unknown names fail; recognised names satisfy this test. Native HTML attribute parsing commonly normalises case, while different parsing contexts require their own consideration.
Critical impact maps to high severity in the supplied integration. The check does not decide whether a recognised attribute is useful, correctly valued, or allowed on the effective role. A missing finding does not verify functionality or broad assistive support.
How to fix it
- Inspect the actual DOM attribute and locate the component or template that emits it. Compare the intended standard name, not only the prop spelling in a source file.
- Correct genuine misspellings, such as aria-labeledby to aria-labelledby. Then verify its referenced ID exists and supplies the intended text; fixing the spelling can expose a separate broken-value relationship.
- Use role for roles, not aria-role. Prefer a native element where its semantics fit instead of inventing attributes to imitate the browser's built-in behaviour.
- For application bookkeeping, choose appropriate data attributes or internal state. For example, data-open may store implementation data, but does not replace aria-expanded where that supported accessibility state is genuinely needed.
- Use defined purpose-specific properties. An accessible name, additional description, live update, and expanded state are different needs. Do not replace every unknown aria-name or aria-tooltip with aria-label without deciding which meaning is required.
- Check specification status and target-client support for unfamiliar newer names. Distinguish the deployed checker vocabulary from published Recommendations and work-in-progress drafts. Document a genuine compatibility limitation instead of silently substituting incorrect semantics.
- Inspect computed accessibility output and exercise the related control. The expected label, state, or description should actually update and remain aligned with visible behaviour.
- Rescan and run name, value, required-property, and role-compatibility checks separately. A vocabulary repair is the first step, not a complete widget audit.
What the fix can break
Renaming an attribute can break internal scripts or styles that were reading the erroneous name. Update those dependencies while giving accessibility semantics their proper standard source.
Adding a now-effective aria-label can override descendant text that previously supplied a name. Inspect precedence and visible-label consistency after the repair.
Do not scatter experimental attributes across production solely to future-proof a component. Use established native behaviour where possible and review the complete support matrix for necessary enhancements.
Questions
Does a known attribute name guarantee a valid widget?
No. Value, role context, required relationships, keyboard behaviour, and state accuracy remain separate.
Will uppercase spelling always fail in HTML?
Not ordinarily, because HTML parsing normalises attribute names. Use canonical lowercase spelling for maintainability and examine non-HTML contexts separately.
Can I invent aria-prefixed metadata for my app?
Do not use the accessibility vocabulary as a custom data namespace. Use a suitable application mechanism instead.
Which related checks help?
Review valid values, supported attributes, and the automation limits guide.
What severity does this get in the report?
High. An axe finding takes its severity from the impact axe reports for the element that failed, and the report maps critical and serious to high, moderate to medium, minor to low. This rule is declared critical in axe-core 4.13.0, so every failure arrives as high - even when the invalid attribute is harmless noise, because the check cannot know what it was meant to do.