Use <button type="button">. Built-in role and keyboard behavior.
Set disabled = true. Browser blocks activation and form use.
Skip aria-disabled for that control — native wins (MDN).
Reach for ariaDisabled mainly on custom widgets without a disabled attribute.
Compatibility
Browser Support
Element.ariaDisabled is Baseline Widely available (MDN: since October 2023). Safe for modern evergreen browsers.
✓ Baseline · Widely available
ariaDisabled
Reflects aria-disabled as the strings true/false for perceivable but inoperable elements.
99%Widely available
Google ChromeAll versions · Desktop & Mobile
Full support
Mozilla FirefoxAll versions · Desktop & Mobile
Full support
Apple SafariAll versions · macOS & iOS
Full support
Microsoft EdgeAll versions · Chromium & Legacy
Full support
Internet ExplorerIE 6+ · Legacy environments
Full support
OperaAll modern versions
Full support
ariaDisabledExcellent
Bottom line: Prefer native disabled on real buttons/inputs. For custom widgets, set ariaDisabled and also block activation in JS.
Frequently Asked Questions
It reflects the aria-disabled attribute as a string ("true" or "false"), indicating the element is perceivable but disabled — so it is not editable or otherwise operable (MDN).
No. MDN marks Element.ariaDisabled as Baseline Widely available (since October 2023). It is not Deprecated, Experimental, or Non-standard.
The strings "true" (disabled but still perceivable) or "false" (enabled).
You assign the strings "true" and "false", not the boolean literals true/false. The property reflects the ARIA attribute value.
Yes when possible. Prefer a real button or form control with the HTML disabled attribute — they have built-in semantics and do not require ARIA (MDN).
No. Unlike HTML disabled, aria-disabled is semantic only. You must also suppress activation (and usually restyle) with your own JavaScript and CSS (MDN).