`aria-disabled` buttons should have same CSS as `disabled`

[coliff]

If you're building a form then you may want the submit button to be disabled until the form has been completed correctly. Using the disabled attribute on the submit button will however not allow the user to tab to it.

A better solution could to be disable click events on the submit button and make the button be announced as disabled with the aria-disabled="true" attribute. If you do that with Bootstrap though it doesn't use the disabled state button CSS. (Quick demo: https://stackblitz.com/edit/bootstrap-disabled-buttons )

I read about this on: https://a11y-101.com/development/aria-disabled

TLDR: A disabled button currently has CSS something like this:

.btn.disabled, .btn:disabled, fieldset:disabled .btn {
   ....
}

I suggest it should include aria-disabled="true" buttons so compiled CSS would be:

.btn.disabled, .btn:disabled, fieldset:disabled .btn, .btn.aria-disabled="true" {
    ....
}

I know there are more accessibility considerations regarding my form scenario example mentioned above, but I still think it probably makes sense for aria-disabled="true" buttons to use the same styles as disabled buttons.

[julien-deramond]

Thanks for this suggestion @coliff.

Edit: Your StackBlitz link seems to be broken, could you please update it if possible?

If I understand the content correctly, we're talking here simply to ensure some visual consistency so that disabled or aria-disabled="true" applied on a button would have the same rendering. My first feeling would be that it could work even if we would need to double-check some edge cases.

@patrickhlauke would it make sense to you to have such a defensive CSS approach or would it be necessary on the contrary to have a different rendering?

[AgentKaash]

Could you @coliff or @julien-deramond tell me, in which section of Bootstrap should i find the actual issue in real time, I opend Bootstrap many times but I couldn't find it.
I want to fix it. My humble request please give me some hints....
Though I am newbie in contribution I am going anywhere whithout solve it.

[julien-deramond]

Thanks @AgentKaash but this is not yet decided whether we're going to make this modification or not. So there's no PR to provide at the moment.

in which section of Bootstrap should i find the actual issue in real time, I opend Bootstrap many times but I couldn't find it

It's not in the documentation. This would be a defensive CSS approach for this use case.

[patrickhlauke]

In principle, I don't have anything against also applying the regular .disabled styling to cases where aria-disabled="true" is set.
Of course, you can achieve this currently by manually adding the .disabled class (like you would with "faked" buttons that use <a>, for instance)

<button type="button" class="btn btn-primary disabled" aria-disabled="true"> … </button>

If we go with these styles being applied out-of-the-box directly based on the aria-disabled attribute, we can then tweak the explanation in https://getbootstrap.com/docs/5.3/components/buttons/#disabled-state about authors needing to add .disabled themselves.

If we don't want to go with this, we can at least expand the explanation in https://getbootstrap.com/docs/5.3/components/buttons/#disabled-state to mention that the same caveat about adding .disabled to links also needs to be done for buttons that aren't really disabled

[developernarendra]

is it something which i can solve?

[patrickhlauke]

We'd probably need to make a decision on which direction to go (see my two suggestions above). @julien-deramond et al?

[julien-deramond]

There are currently 7 occurrences of .disabled in bootstrap.css:

.btn:disabled, .btn.disabled, fieldset:disabled .btn {
  /* ... */
}
.dropdown-item.disabled, .dropdown-item:disabled {
  /* ... */
}
.nav-link.disabled, .nav-link:disabled {
  /* ... */
}
.page-link.disabled, .disabled > .page-link {
  /* ... */
}
.list-group-item.disabled, .list-group-item:disabled {
  /* ... */
}
.btn-close:disabled, .btn-close.disabled {
  /* ... */
}

I would go with the following strategy:

1. Determine for each use case if :disabled or aria-disabled="true" (depending on the use case) would be enough. Said differently, are there any use cases when :disabled or aria-disabled="true" can't be used, and we still need to force .disabled somewhere?
2. If enough, we could apply temporarily the disabled state for :disabled + .disabled or aria-disabled="true" + .disabled for a v5.4 (or v5.x). And not necessarily modify the documentation as .disabled is still working.
3. And later, because it's breaking, in the v6, get rid of .disabled entirely in the CSS rules, and update the documentation.

If it makes sense for each component, and we don't find weird edge cases, we would enforce accessibility even more by getting rid of a useless .disabled class.

Thoughts @twbs/css-review or here?