-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Find consensus around using cursor: not-allowed
on disabled elements and apply across
#63756
Comments
We change the cursor to |
Yes, |
I definitely agree that we should align cursor styles across the project, and I'm ok with not using I have some doubts on using |
I'll also add that the standard guidance is to use |
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 ( Doing something with the cursor can better help communicate the status, regardless of context. I suppose one thing to try is applying I'd welcome a11y input on this subject, cc: @joedolson. |
Using We should definitely be consistent across the board with this, though; having mixed behaviors definitely doesn't help users. |
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:
The text was updated successfully, but these errors were encountered: