Find consensus around using `cursor: not-allowed` on disabled elements and apply across

[jameskoster]

Some components (e.g. DropdownMenu V2) apply cursor: not-allowed to disabled elements. Most components do not. Ideally this pattern is applied consistently across.

One argument for the cursor change is that it provides an additional hint when context is lacking. For example in this mockup a user could easily mistake the disabled input for a regular input:

[mirka]

We change the cursor to pointer on almost all interactive elements (or text if text field), so changing it back to the default cursor when disabled should be good enough? I'm afraid it would be distracting to show a not-allowed cursor — almost like it calls for more attention. I could maybe understand if we were using default cursors for interactive elements (which is the browser default for <select>, <button>, etc), but in our case, "is it a pointer or not" is already a pretty sufficient cursor-based indicator of interactivity.

[jameskoster]

Yes, cursor: default in the absence of a pointer to indicate the disabled state makes sense to me. If that's the way to go we should align the new dropdown menu to that convention. Currently enabled menu items show the default cursor.

[ciampo]

I definitely agree that we should align cursor styles across the project, and I'm ok with not using cursor: not-allowed for disabled options.

I have some doubts on using cursor: pointer for standard option items (menus, selects, etc). Both in standard HTML elements (select) and in most major UI libraries (ariakit, radix, react aria..) the cursor is always set to default, and the main way to visually indicate visual items are dimmed text and no hover effects. Of the UI libraries I checked, only Chakra UI seems to be using cursor: pointer.

[mirka]

I'll also add that the standard guidance is to use cursor: pointer for links only.

[jameskoster]

main way to visually indicate disabled items are dimmed text and no hover effects.

The concern with relying purely on this is that additional context is required to understand the disabled state. IE you need to know that hover effects exist in the first place before you can notice that they're missing. This is less reliable when not all interactive elements have hover effects (TextControl does not, arguably it should, but that's another story). Color alone can be inadequate from an a11y perspective.

Doing something with the cursor can better help communicate the status, regardless of context.

I suppose one thing to try is applying cursor: not-allowed to disabled elements across the board. Then elements like select can still use the default cursor on enabled options.

I'd welcome a11y input on this subject, cc: @joedolson.

[joedolson]

Using cursor: not-allowed on disabled elements is a pretty common way of providing an external indicator for users that something is disabled. Since it's standard to design disabled elements with low contrast (and they are an allowed exception in WCAG for being below color contrast requirements), it's valuable to have at least one indicator that can be at full contrast, and the mouse cursor is able to provide that. For keyboard users, there's an open issue to improve the contrast of the focus ring, which provides a similar aid for people not using a mouse.

We should definitely be consistent across the board with this, though; having mixed behaviors definitely doesn't help users.