A disabled button should either leave the keyboard tab sequence or remain focusable based on what users need to discover in that interaction—not according to a universal rule. Use native disabled when skipping an unavailable action is appropriate; consider aria-disabled="true" when users need to reach the control and learn why it is unavailable. In either case, explain how to make the action available, and ensure the button cannot be activated while unavailable.
Should disabled buttons be focusable?
Sometimes. A native HTML button with the disabled attribute cannot be activated and is removed from the keyboard tab order. This reduces keyboard stops, but people who find controls by moving focus may be less likely to encounter the button or its explanation. The W3C ARIA Authoring Practices keyboard interface guidance notes that screen reader users are less likely to discover disabled elements that are not focusable because moving focus is a primary discovery method.
Keeping an unavailable control focusable can make its state and associated explanation easier to find. But an extra focus stop is not automatically helpful. Choose a consistent pattern for similar controls, considering the flow and whether the reason for unavailability needs to be discovered at the button. For controls inside a composite widget, follow that widget’s keyboard interaction pattern rather than making each child a page-level tab stop.
Should I use disabled or aria-disabled?
| Consideration | Native disabled |
aria-disabled="true" |
|---|---|---|
| Prevents activation | Yes. The native button is disabled. | No. Your application must block activation. |
| Keyboard focus | Removed from the tab order. | Can remain focusable, depending on how you implement it. |
| Discoverability | Fewer tab stops, but focus-based navigation may skip the control and its explanation. | Can let users reach the unavailable control and its associated explanation. |
| Implementation | Uses native behavior and browser styling. | Requires activation guards and author-supplied styling, including attention to contrast and forced-colors presentation. |
Both approaches communicate that an action is unavailable, but they do different things. Use a semantic <button> for an action; the U.S. Web Design System button guidance advises against making buttons from generic elements because assistive technology does not automatically identify those elements as usable buttons.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11#1 Best Overall
Choose native disabled when skipping the control is appropriate
A native disabled button is a good fit when an unavailable action does not need to be reached by keyboard, and nearby content already makes the state or next step clear. It prevents activation without requiring you to write a separate guard. Because focus skips it, do not make it the only place where a user can discover why an action is unavailable.
Choose aria-disabled when the unavailable control needs to be discoverable
Use aria-disabled="true" when users should be able to focus the button—for example, when reaching the unavailable action is important for discovering its explanation. The attribute exposes the unavailable state to assistive technology but does not suppress clicks, keyboard activation, or application behavior. Your code must prevent every relevant activation path.
Rank #2
Consider whether a disabled button is needed
The W3C Design System button guidance says, “Disabled buttons can confuse some users, so avoid them if possible.” If the next action can instead be explained through the form or flow without presenting an unavailable button, that may be clearer. Use disabled controls when they make the interface easier to understand, not merely because an action is not yet available.
How do I explain why a button is disabled?
State both what is unavailable and what the user can do to make it available. “Complete the required field above to submit” is more useful than a button that only looks inactive. Put essential instructions in text that remains visible; a hover-only tooltip is not available to everyone. Designsystemet recommends supporting text that remains visible when a button is disabled in its button guidance.
Place the explanation near the button or the relevant field, and ensure keyboard users and assistive-technology users can access it. If you associate a description programmatically with the button, verify that it is announced in the intended context in the browsers and assistive technologies your product supports. A visual proximity alone does not guarantee that a screen reader will announce the text as part of the button.
How to implement a focusable unavailable button
This example leaves the button focusable, exposes its unavailable state, and links it to visible guidance. The handler guard is still essential: ARIA and styling do not block activation.
<p id="submit-help">Complete the required fields to submit.</p>
<button type="button"
aria-disabled="true"
aria-describedby="submit-help"
onclick="if (this.getAttribute('aria-disabled') === 'true') return; submitForm();">
Submit
</button>In a production application, enforce the unavailable state in the application’s event handling, not only in an inline handler. Guard pointer and keyboard-triggered activation paths, including any form submission logic that could invoke the action without clicking the button. Update the state and its explanation when the user completes the requirements, and test that the action becomes available at the right time.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How to style and test unavailable buttons
A dimmed appearance does not explain why a button is unavailable. Keep the state visually distinguishable, make focus visible when the control can receive focus, and preserve legibility. Do not reduce contrast indiscriminately for a focusable unavailable control: MDN’s aria-disabled guidance notes that content which remains focusable and important to perceive may need styling that still meets contrast requirements, including in forced-colors mode.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Best Value
- Check keyboard focus order and confirm that a focusable unavailable button has a visible focus indicator.
- Use a screen reader to check that the button’s unavailable state and any associated explanation are announced where users need them.
- Try pointer and keyboard activation, plus any other application path that could trigger the action; confirm the action is suppressed while unavailable.
- Check that the reason and the steps to enable the action are visible and accessible.
- Review contrast and forced-colors presentation for the actual unavailable and focused states.
Test the real interaction flow rather than relying on an automated check alone. The appropriate pattern depends on context, so validate it with users and in the keyboard and assistive-technology environments relevant to your product.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
