Prohibited ARIA attributes must not be used for roles in UI

Prohibited ARIA attributes must not be used for a role

Do not apply ARIA states or properties that the element’s role forbids.

This issue appears when aria-* attributes are set on elements with implicit or explicit roles that do not support them.

Users of screen readers and other assistive tech can miss key state information or hear confusing, conflicting output.

Why It Matters

Invalid ARIA changes the accessibility tree. Assistive technologies may ignore the attribute or guess, causing incorrect announcements.

When the announced role and state do not match the widget’s behavior, users may take the wrong action or abandon the task.

People using screen readers, switch controls, or voice input are most affected, but all users can be impacted by broken widgets.

Common Causes

• Copy-pasting components that include aria-* without checking role support
• Assuming all aria-* attributes are global and allowed everywhere
• Using an attribute meant for another widget (e.g., aria-checked on a button)
• Over-specifying roles on native controls, creating role/attribute conflicts
• Frameworks or libraries that add generic aria-* to many elements
• Setting presentational roles (role="none"/"presentation") while leaving interactive aria-* states

How to Fix

• Determine the element’s role: identify native semantics (implicit role) or the explicit role attribute.
• Check the WAI-ARIA role definition to see which states and properties are supported, required, or prohibited for that role. Do not assume an attribute is global.
• If an attribute is prohibited for the current role:
• Remove it if it does not convey essential information, or
• Change to a role that supports the attribute and meet that role’s requirements, or
• Move the attribute to the element that actually owns the behavior and supports it, or
• Prefer a native HTML element that already exposes the needed state.
• Keep states in sync with UI behavior (e.g., update aria-pressed when a toggle changes, aria-expanded when a disclosure opens).
• Re-test the component’s role and attributes after changes.

How to Test

• DevTools inspection: In browser accessibility tools, inspect the element. Confirm the exposed role and verify that each aria-* property is supported for that role. Watch for “Invalid ARIA” warnings.
• Keyboard check: Operate the control with Tab/Shift+Tab and Enter/Space. Confirm the visual state and the aria-* state update together.
• Screen reader check: With NVDA/JAWS/VoiceOver, navigate to the control. Ensure the role and state announced match the widget (e.g., “toggle button, pressed”). No extra or contradictory states should be announced.
• Mobile/touch check: With VoiceOver or TalkBack, focus the control. Verify the rotor/verbosity announces the correct role and state.
• Automated checks: Run accessibility linters or testing tools. Review any rules that flag disallowed ARIA for roles (ACT Rules-based tests can help identify patterns).
• Simple checklist:
• The role is correct for the widget.
• All aria-* used are allowed for that role.
• Required states for that role are present.
• No prohibited attributes remain.
• States change programmatically with interaction.

Good Example

A toggle button uses an allowed ARIA state for its role.

<button type="button" class="mute" aria-pressed="false" aria-label="Mute audio">Mute</button>
<script>
  const btn = document.querySelector('.mute');
  btn.addEventListener('click', () => {
    const pressed = btn.getAttribute('aria-pressed') === 'true';
    btn.setAttribute('aria-pressed', String(!pressed));
    btn.textContent = pressed ? 'Mute' : 'Unmute';
  });
</script>

Bad Example

A button incorrectly uses aria-checked, which is prohibited for the button role.

<button type="button" aria-checked="true">Mute</button>

Quick Checklist

• Identify the element’s implicit or explicit role
• Verify each aria-* is allowed for that role in WAI-ARIA
• Do not assume attributes are global; check the spec
• Prefer native elements that expose correct roles/states
• Remove or relocate any prohibited attributes
• Keep ARIA states synchronized with interaction and visuals
• Validate with DevTools and automated accessibility tests
• Confirm correct announcements with at least one screen reader