Problem/Motivation

There's research to prove that using disabled button elements is bad for usability and accessibility. For example, Disabled buttons suck provides a comprehensive explanation of why disabled buttons shouldn't be used, and what should be used to replace them.

The core problem is that when a button is disabled, the user won't know why it is disabled. Preventing actions could be still done by either not showing the button at all, or by showing the button as active, and after a user clicks a "disabled" button, the system would show an error including an explanation of why the action couldn't be triggered.

At the moment, we support the disabled state by specifically adding classes to buttons based on disabled state. We also provide styles for the disabled state in our themes.

Proposed resolution

Deprecate disabled state for buttons in Drupal 8.8.0 and explain that all explicit support for them will be removed in Drupal 9. Since we don't want to be on the way of people, people should be still allowed to pass in the attribute buttons but it wouldn't be supported by Drupal themes out of the box. This way people would be still able to achieve the same end result in custom projects, but we discourage contrib projects and core from using this pattern.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Comments

lauriii created an issue. See original summary.

andrewmacpherson’s picture

andrewmacpherson commented
Issue summary: View changes

I'm very skeptical of this. Whatever the problems with disabled buttons (especially styling), they are part of the HTML rec, and I don't think we can ignore that. Developers WILL create disabled buttons in their custom modules, and if core themes don't support this, users will have no way to know that the button is disabled, and that will be the fault of our core themes.

There's an interesting response to the axesslab article here - https://medium.com/@DanielKoster/disabled-buttons-dont-have-to-suck-6dcd...

andrewmacpherson’s picture

andrewmacpherson commented

Preventing actions could be still done by either not showing the button at all, or by showing the button as active, and after a user clicks a "disabled" button, the system would show an error including an explanation of why the action couldn't be triggered.

Both these suggestions can work, but they depend on the context of the application. These might be interesting to create as separate FAPI element types, with their attached behaviours.

Since we don't want to be on the way of people, people should be still allowed to pass in the attribute buttons but it wouldn't be supported by Drupal themes out of the box.

The problem with this is that it segregates users even more. Sighted users without assistive will see a button, but not know that it is disabled. Meanwhile the disabled attribute will be programatically conveyed to assistive tech, so some users will indeed know that it's a disabled button.

Browsers have default styles for disabled buttons. If our core themes override button styles, and don't provide a style for disabled buttons, then the core theme is actually less accessible/usable/informative than the browser style.

lauriii’s picture

lauriii
he/him
Primary language Finnish
Location Finland
commented

The problem that I tried to convey is that from our documentation, and API point of view, there's no risk at all in marking buttons disabled. There's explicit support for that. Also because we are lacking metadata, it's not possible to fix this in theme level.

AFAIK, there aren't any excuses for marking button disabled without providing an explanation of why the button has been disabled. If an explanation isn't provided, there's always room a chance that some users get confused. Given that, maybe a better solution would be to provide an opinionated way to mark buttons as disabled that would require providing a message on why the action cannot be run. This could be implemented differently by each theme.

Often times buttons are disabled for no good reason. Requiring a message forces developers to think about why the button was disabled and could lead to them finding better alternative solutions. For example, what Drupal core does if user is lacking permissions for triggering an action, the button is simply not shown for the user.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

mgifford’s picture

mgifford
he/him
Primary language English
commented
Issue tags: +disabled elements

Just adding some more research to this:

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

mgifford’s picture

mgifford
he/him
Primary language English
commented

It's been 3 years, so here are some updated references (via AI):

  • MDN: aria-disabled, updated November 2025. Explains the difference between native disabled and aria-disabled.
  • MDN: inert. Relevant when an entire region, rather than one form control, must be temporarily unavailable. Inert content is removed from both the tab order and accessibility tree, so it is not interchangeable with disabled.
  • WHATWG HTML: disabled form controls. This should be the normative HTML reference.
  • WAI-ARIA 1.2: aria-disabled. This defines the programmatic state, but does not supply behaviour.
  • GOV.UK Design System: disabled buttons. GOV.UK says to avoid them where possible and use them only when research shows that they make the interface easier to understand.
  • WCAG 2.2, 1.4.3 and 1.4.11. WCAG explicitly exempts inactive controls from the minimum contrast requirements. That is an exception, not a recommendation to make them difficult to see.
kentr’s picture

kentr commented
Status: Active » Needs review
Issue tags: +Usability, +Needs usability review

To me, this goes beyond accessibility b/c it affects every user.

I'm curious about the usability team's opinion. Setting to Needs review b/c I think they use that tag to find issues for UX review.