In one paragraph
Elements must only use permitted ARIA attributes means a tested role or host-language context prohibits a declared property. Common cases involve naming generic or presentational content as though it were a meaningful labelled object. Identify the actual purpose and move or repair the semantics appropriately. Do not add an image, group, or region role solely to make a label pass without a corresponding user need.
Why it matters
An accessible name belongs to an element with semantics that support naming. Putting aria-label on a generic styling span does not reliably create a useful labelled interface object. Where text itself should convey information, ordinary visible content can be the better solution.
A label can also be attached to the wrong node. Naming an icon wrapper does not automatically name its enclosing button, and flattening a whole interactive group into an image can remove necessary structure.
Global-looking ARIA properties still have host-language or role-specific constraints. Do not interpret a general attribute list as permission to use every name on every element. Computed role, actual HTML restrictions, and current specification support all matter.
How WebAuditOS evaluates this finding
The supplied aria-prohibited-attr rule checks declared attributes against the applicable prohibited set. Its source describes special handling for generic native elements, explicit roles, custom elements, and context inside widgets.
Serious impact maps to high severity. Some cases with content or ambiguous naming references are returned for review rather than violations and therefore omitted from the described report. A quiet result on a labelled span is not proof its label is used or semantically appropriate.
How to fix it
- Inspect the rendered element and computed role. Determine whether the information is ordinary text, a noninteractive graphic, a real group, a landmark, or a control that should receive the name elsewhere.
- If ordinary text carries the meaning, publish that text appropriately rather than hiding it only in an unsupported label. A status word such as Online can often be real content without inventing a new object role.
- For an actual control, name the control itself. For example:
<button type="button" aria-label="Call support"><span aria-hidden="true">Phone</span></button>This is a naming illustration, not a complete call integration. Choose visible wording or artwork appropriate to the actual design and implement the action.
- For a genuine single graphic, an appropriate image role and useful name can fit. Do not use that role on content whose inner links or fields need to remain independently available.
- Add group or region semantics only when they express a real useful structure. Creating a named region for every decorative wrapper can clutter navigation while making a prohibited-name warning disappear.
- Remove presentation or none only if meaningful semantics should actually be present. A conflict between a presentational declaration and naming should be resolved by intent, not whichever change most quickly clears the report.
- Test computed names, reading order, visible meaning, and dynamic status. A correctly spelled label can still be unused, overridden, or attached to the wrong repeated instance.
- Rescan prohibited, supported, valid-name, and value rules together and manually review incomplete results. Treat authoring correctness as more than a presence test.
What the fix can break
Changing roles can make a simple container announce as a landmark or object and alter descendant interpretation. Evaluate the resulting navigation burden.
Deleting a prohibited label can remove the only intended information. Replace it with a valid communication path rather than losing content to satisfy syntax.
Do not assume an automated review omission means the implementation is allowed in every browser or role model. Confirm against actual semantics and appropriate HTML guidance.
Questions
Is aria-label appropriate on every div or span?
No. Review actual role and host-language naming restrictions instead of assuming a generic wrapper is a named object.
Should I add role=img just to allow a label?
Only when the content really is a single informative graphic and that semantic model fits.
Why was a suspicious named span not reported?
The supplied engine can return some such cases for review, which its failures-only report omits.
Which related checks help?
Review supported attributes, image alternatives, 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 serious in axe-core 4.13.0, so every failure arrives as high.