Elements must only use supported ARIA attributes

Who this affects

These elements carry ARIA attributes that their role does not support. Assistive technology may ignore the attribute, or announce a state that does not match what is on screen — for example a field announced as required when it is not, or the reverse.

How to fix it

Either give the element a role that supports the attribute, or move the attribute to the element it actually describes. A common case is aria-required on a wrapper <div> instead of on the <input> itself.

Effort Low · ~15 min per element

Before and after

<div role="heading" aria-required="true">
  Delivery
</div>

<h2>Delivery</h2>

Where this sits in the standard

EN 301 549 clause 9 applies these criteria to web content. The published version referenced by the European Accessibility Act is V3.2.1, which incorporates WCAG 2.1 level A and AA. More on the standard.

How to check it by hand

Inspect the element in the browser's accessibility tree — the Accessibility panel in Chrome or Firefox DevTools. Compare the computed role, name and state with what a sighted user sees. Where they disagree, the ARIA is wrong. Native HTML is almost always the safer fix.

Automated testing settles roughly a third of the WCAG success criteria. This rule is one an automated tool detects reliably — but a clean automated result is not proof of conformance.

Reference

Deque's technical write-up for this rule: aria-allowed-attr