Skip to content
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

Default colour of the Disabled items text could be lighter. #32474

Closed
emfluenceindia opened this issue Dec 14, 2020 · 10 comments · Fixed by #32785
Closed

Default colour of the Disabled items text could be lighter. #32474

emfluenceindia opened this issue Dec 14, 2020 · 10 comments · Fixed by #32785

Comments

@emfluenceindia
Copy link

Hi,

Can we make the default text colour of Disabled Link (Dropdown and Tab items) bit more lighter?
Currently this is pretty close to that of Active item's text colour.

My suggestion is instead of $gray-600 (#6c757d), we may use $gray-400 (#ced4da) for .disabled class. (src/scss/_variables.scss).

Please see the difference in the following screenshots

Dropdown
1

Tabs
2

Also, adding the .disabled class to links might also use a different colour, but when the click is enabled (but the default behaviour is prevented), we could use the same blue colour.
However, if the click is not enabled, we might use a lighter colour as well telling that link is available but not clickable. May be we can use the same $gray-400 for this as well!

An use case maybe a role based restrictions.

UPDATE
I tried to create a Pull Request instantly at #32473. This is probably not the right way of doing this. Sorry for that.

@patrickhlauke
Copy link
Member

while for disabled controls there's no direct WCAG minimum contrast requirement, I'd still say that $gray-400 is just a little bit too uncomfortably low (1.5:1 against white). maybe $gray-500 #adb5bd (which gives 2:1 against white) may be a good compromise?

@emfluenceindia
Copy link
Author

while for disabled controls there's no direct WCAG minimum contrast requirement, I'd still say that $gray-400 is just a little bit too uncomfortably low (1.5:1 against white). maybe $gray-500 #adb5bd (which gives 2:1 against white) may be a good compromise?

Yes, you are right! In fact after sending this I tried with $gray-500, and this indeed looks much better than $gray-400. :)

@mdo
Copy link
Member

mdo commented Dec 15, 2020

@patrickhlauke I’d be okay with that I think! Depends on @twbs/css-review feedback on lowering contrast ratios.

@ffoodd
Copy link
Member

ffoodd commented Dec 15, 2020

I'd be against this — but as @patrickhlauke mentionned, disabled things are still an exception when it comes to contrasts, sadly!

Since it's very easy to customize, your call.

@emfluenceindia
Copy link
Author

@ffoodd I think it is easy for people to understand between active and disabled items if they are well distinguished. If you don't mind I would like to know why you don't like the idea. Sorry for asking.

@patrickhlauke
Copy link
Member

it's the tension between signalling visually that something is disabled, while also actually allowing users to see it properly. even somebody who may have low vision / difficulty in distinguishing colour well may want to be able to see that yes, there's something there, just that it's currently disabled - they can get information from that, the same way users with good vision can. but when contrast is too low, they'll struggle. this is why WCAG defines baseline color contrast ratios that we try to follow...but as it explicitly exempts disabled controls, the ratios don't apply...

so it's a case of weighing up "we're allowed to do it" vs "how far should we go to still make it usable/useful regardless"

@ffoodd
Copy link
Member

ffoodd commented Dec 15, 2020

IMO, if your disabled control is so useless that you don't care it's barely invisible, why not simply drop it?

This is a gross way to highlight the issue, but some patterns in the wild are really difficult: say a submit button is disabled until something happens and has low contrasts, it could be missed — then its state update could be missed too, and your user gets stuck.

So yeah, WCAG does not ask for disabled things to provide sufficient contrast, yet it can (and probably will) be an issue.

@MartijnCuppens
Copy link
Member

FWIW, our disabled buttons don't have enough contrast either but a lot of A11Y tools won't complain about that since they can't deal with opacity.

Wild idea: would it be better/make sense to add an aria-label attribute if we lighten the text color?

@patrickhlauke
Copy link
Member

Wild idea: would it be better/make sense to add an aria-label attribute if we lighten the text color?

aria-label is only announced by assistive technologies (screen readers, some screen magnifiers with additional voicing capability). they will also, like normal, just announce whatever the text of the control/button is even when disabled. so, it wouldn't make any difference for users who can actually make use of aria-label, and it won't help users who are affected by low contrast, i.e. generally users without assistive technologies who just happen to have low vision/color blindness.

@mdo mdo added this to Inbox in v5.0.0-beta3 via automation Jan 13, 2021
mdo added a commit that referenced this issue Jan 13, 2021
@mdo
Copy link
Member

mdo commented Jan 13, 2021

Opened #32785 to tackle this.

v5.0.0-beta3 automation moved this from Inbox to Done Jan 15, 2021
mdo added a commit that referenced this issue Jan 15, 2021
XhmikosR pushed a commit that referenced this issue Jan 15, 2021
XhmikosR pushed a commit that referenced this issue Jan 15, 2021
@XhmikosR XhmikosR removed this from Done in v5.0.0-beta3 Jan 15, 2021
@XhmikosR XhmikosR added this to Inbox in v5.0.0-beta2 via automation Jan 15, 2021
@XhmikosR XhmikosR moved this from Inbox to Done in v5.0.0-beta2 Jan 15, 2021
@XhmikosR XhmikosR moved this from Done to Inbox in v5.0.0-beta2 Jan 15, 2021
@XhmikosR XhmikosR moved this from Inbox to Done in v5.0.0-beta2 Jan 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
v5.0.0-beta2
  
Done
Development

Successfully merging a pull request may close this issue.

5 participants