State Global state

`aria-disabled`

Indicates that a control is perceivable and focusable but does not respond to user input. Prefer the native HTML disabled attribute when available; reach for aria-disabled when you need the element to remain focusable or to receive a tooltip.

When to use

When a button, link, input, or composite widget is currently inoperable but should still appear in the tab order so users can discover it and learn why it is disabled. Set aria-disabled="true" and visually style it so the disabled state is unambiguous.

Compared with related attributes:

HTML disabled (on <button>, <input>, <select>, <textarea>, <fieldset>) — removes the control from the tab order entirely, ignores clicks, and prevents the value from being submitted. Use this when there is nothing for the user to do with the control.
aria-disabled="true" — the screen reader announces “dimmed” / “unavailable”, but the element stays focusable. You must also prevent the click handler from running. Use this on custom widgets, on <a> tags (which don’t accept disabled), or when the disabled state needs a tooltip explaining why.
aria-readonly — value cannot be changed but the control is still operable and focusable. The user can copy it, the form will still submit it.
aria-hidden — removes the element from the accessibility tree entirely. Different goal: hidden, not disabled.

How to keep it in sync

Valid values are "true" and "false". Default to "false" or omit when enabled — there is no need to render aria-disabled="false" on every active control.

When aria-disabled="true":

Stop the click handler from running. The attribute does not block events on its own.
Prevent default keyboard activation (Enter, Space).
Ensure the visual style makes the disabled state obvious; check it still meets WCAG 1.4.11 non-text contrast (the disabled appearance is explicitly exempt, but a clear visual cue is still better practice).

Common failures

Using aria-disabled="true" without blocking the click handler — the element looks dim but still fires its action.
Using both disabled and aria-disabled on the same element. The native attribute already exposes the state; the duplicate is redundant.
Using aria-disabled on <a> without also removing href or preventing default — the link still navigates.
Disabling controls without explaining why. WCAG 3.3.1 expects an error or instruction.
Confusing aria-disabled with aria-hidden. Disabled elements remain in the accessibility tree; hidden elements vanish.

Example

<button type="submit" aria-disabled="true" aria-describedby="submit-help">
  Submit order
</button>
<p id="submit-help">Add at least one item to your cart to enable submit.</p>