I have tested this item ✅ successfully on 219fc74

GREAT fix - thank you

I'm not sure this change is an improvement. Making the button reachable doesn't add helpful information, the screen reader announces it as "not available dropdown", so now the user knows there is an actions button there, but doesn't know what to do with it.

https://www.codestudy.net/blog/when-to-use-the-disabled-attribute-vs-the-aria-disabled-attribute-for-html-elements/
https://kittygiraudel.com/2024/03/29/on-disabled-and-aria-disabled-attributes/

@drmenzelit I massively disagree

Hii @drmenzelit !!

The goal of this change is mainly to improve discoverability for keyboard and assistive technology users. When the native disabled attribute is used, the element is removed from the tab order entirely, which means keyboard users may not be aware that these actions exist

using aria-disabled="true" keeps the button focusable while still conveying that the action is currently unavailable. The existing component logic already prevents execution when no items are selected, so the behavior remains unchanged.

A whole point of use native <button> element in the toolbar is to support native browser behavior without such workarounds.

I am on a side with @drmenzelit

@Fedik it's not a work around. This is exactly the correct way to mark a button as disabled to assistive technology. Without it the button is invisible

This is exactly the correct way to mark a button as disabled to assistive technology. Without it the button is invisible

You do not find strange that native browser element need such thing?
To me it is something wrong with suggested approach. We maybe missing something.

@drmenzelit wrote: so now the user knows there is an actions button there, but doesn't know what to do with it.

is there an aria- feature that can let say "explain the dropdown/button behavior"? kind of aria-label but not exactly.
Something like "Button is disabled until action XY happened". Or maybe use aria-label?

I mean, from what I read/understood the screen reader can see the disabled button,
But do not explain that the button can change state (and how to change the state). Nor current PR.

@Fedik One option might be using aria-describedby to reference a short hint explaining the condition, for example that the action becomes available once an item is selected. that way the button remains discoverable while also giving screen reader users some context about how the state can change

I mean, from what I read/understood the screen reader can see the disabled button,

No it cant and thats the problem being solved here

I got an answer from someone working on accessibility (it is similar to other explanations we have already posted here). It is correct to use ara-disabled to make the button accessible, my criticism is the missing information about the function of the button.

For this use case, I'd recommend aria-disabled="true" with clear context. The button should remain focusable with a label like "Actions (select items to enable)" and include aria-describedby pointing to text explaining why it's disabled. This way screen readers can discover it and understand the requirement, unlike true disabled which removes it from keyboard navigation entirely.
For disabled buttons on a toolbar — keep it in the tab order. Screen reader users need to know the button exists even when it's unavailable, otherwise they won't know the feature is there at all. Use aria-disabled="true" instead of the disabled attribute so it stays focusable. Then announce why it's disabled via aria-describedby.