In one paragraph
Aria-roledescription must be on elements with a semantic role means custom role wording needs an appropriate underlying semantic role to describe. The attribute does not create a role, name the element, or install interaction. Use it sparingly and preserve understandable behaviour. According to the supplied WebAuditOS specification, the deprecated rule is not executed in its current tag-based run, so no finding is not validation.
Why it matters
A role description supplies author-localised wording that assistive technology may use when presenting an existing role. It changes the human-facing description, not the actual semantics or required widget behaviour. A button does not become a new standard interaction type because it is described as an action.
Custom wording can help in a specialised pattern, but familiar role terms tell users how to operate controls. Replacing a recognised button or checkbox description with vague marketing language can remove useful clues. An accurate accessible name and native role often suffice without this override.
Generic or presentational containers do not provide a meaningful foundation for an arbitrary custom widget description. Choose structure according to the task, and do not add another role solely to make an unnecessary roledescription pass a historic test.
How WebAuditOS evaluates this finding
The supplied source describes legacy aria-roledescription logic with a limited acceptance set, failures for missing or presentation-like roles, and review outcomes for other semantic cases. It also states the rule is deprecated and excluded from the documented WCAG-tag execution.
As described, the report therefore raises no finding from this rule. Its nominal serious impact is not a reported severity. Verify the deployed version and selection before presenting that as current behaviour, and do not treat the old acceptance list as the full modern authoring model.
How to fix it
- Inventory actual aria-roledescription usage and identify the intended user benefit. A branding request or unfamiliar internal component name is not by itself a reason to replace standard role wording.
- Inspect the computed semantic role and accessible name. Fix missing base semantics or naming through the appropriate native or ARIA mechanism first.
- Prefer removing an unnecessary custom description while retaining useful native semantics. A clearly named native button generally does not need its role renamed to action or trigger.
- If the chosen supported pattern genuinely benefits from specialised wording, use a short accurate localised description. Keep the name separate: an item position or subject and its role description serve different purposes.
- Preserve the complete interaction model. A role description such as slide does not implement carousel controls, keyboard navigation, pause behaviour, or content relationships.
- Review speech and braille variants where used. A braille role-description override needs its appropriate ordinary counterpart, but both should exist only where justified. Do not add redundant specialised text merely to satisfy a legacy rule page.
- Test with relevant supported assistive technology and settings. Some consumers may ignore custom wording, so the ordinary semantics and name should still support an understandable interface.
- Maintain manual review notes and rescan other applicable roles and naming checks. The documented absence of this particular finding cannot certify correct role descriptions.
What the fix can break
Overriding a familiar term can make keyboard expectations less obvious. Retain recognisable semantics and avoid implying a different interaction than the one actually provided.
A global design-system prop can spread one inappropriate custom phrase across unrelated controls. Scope the feature intentionally and review translated wording.
Do not label an arbitrary div as a rich widget solely to make roledescription meaningful. A valid attribute relationship can still describe a completely unsuitable component model.
Questions
Does aria-roledescription create a role?
No. It provides custom human-readable wording for an appropriate existing semantic role.
Does it replace the accessible name?
No. The element still needs its applicable name and other semantics.
Why is there no current finding in the report?
The supplied specification says the legacy rule is excluded from its tag-based execution. That is a coverage limit, not approval.
Which related checks help?
Review braille equivalents, valid roles, and the automation limits guide.
What severity does this get in the report?
None, because the finding does not appear. Severity for an axe finding comes from the impact axe reports for the element that failed - for this rule, serious, which we would map to high. But axe 4.13 marks the rule deprecated and does not execute it in a tag-based run like ours, so there is no result to grade.