Page MenuHomePhabricator

Disabled OOjs UI button in MediaWiki theme needs more contrast
Closed, ResolvedPublic

Description

Looking over the shoulder of several people over the last few days I noticed the label is pretty much unreadable on most screens I've seen in the wild. Pretty sure this doesn't live up to our standards.

Original – definitely poorCurrent – still not good enough?With overhauled color palette as of https://gerrit.wikimedia.org/r/309483

Event Timeline

Krinkle created this task.Jan 30 2015, 12:44 AM
Krinkle raised the priority of this task from to Needs Triage.
Krinkle updated the task description. (Show Details)
Krinkle added a project: OOUI.
Krinkle added a subscriber: Krinkle.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 30 2015, 12:44 AM
matmarex set Security to None.
matmarex added subscribers: Catrope, matmarex, Isarra.
Jdforrester-WMF triaged this task as Medium priority.Jan 30 2015, 1:20 AM
Jdforrester-WMF added a project: Accessibility.
matmarex raised the priority of this task from Medium to High.Feb 8 2015, 9:32 PM
matmarex updated the task description. (Show Details)
matmarex added subscribers: TrevorParscal, Esanders.

According to M37 frameless buttons should be #CCC which looks better.
According to T88483 the background for disabled buttons should be #DDD which again looks better.

@violetto, are these the final colors?

Elitre added a subscriber: Elitre.Feb 11 2015, 10:19 PM
matmarex closed this task as Resolved.Feb 17 2015, 2:12 PM
matmarex assigned this task to Prtksxna.

Looks all fixed now.

According to M37 frameless buttons should be #CCC which looks better.

Fixed in 528cb6717f824f7c1e0abb1590be97b1d0f13825.

According to T88483 the background for disabled buttons should be #DDD which again looks better.

Fixed in 529ac21ee17005d36466342bcccb768889adb676.

@Prtksxna, yes those color values are accurate. I checked the updated demo today and they look great.

Jdforrester-WMF moved this task from Backlog to Reviewing on the OOUI board.Mar 26 2015, 9:00 PM

I'd suggest re-opening this task, or possibly filing a separate task, because

  • the disabled buttons are still quite hard to read, and
  • often contain important instructions.

E.g. the examples in https://www.mediawiki.org/wiki/Extension:InputBox#Parameters
and this screenshot of a live page

Danny_B moved this task from Unsorted to OOUI on the UI-Standardization board.May 20 2016, 9:00 PM
matmarex reopened this task as Open.May 21 2016, 7:08 AM
matmarex updated the task description. (Show Details)
matmarex added a subscriber: Volker_E.

From an UI perspective this is an issue in many different use cases, for example people with wrong/low contrast settings (display mode night reading in bed), on glossy displays with light sources opposing them (outside in the sunlight) and most important, people with visual impairments.
Citing from https://phabricator.wikimedia.org/T89271#1922397 for any combination white and text #949494 is the minimum contrast color to pass large text on WCAG level AA, which doesn't fulfill all needs of all possible users. Even more, it gives, if used as background-color with white text too much weight to the disabled element compared to the enabled ones.
The other boundaries are #767676 for passing AA on normal text and #595959 for passing AAA on normal text.

The most recent mockup M101 for the buttons tried to circumvent that issue with those high-contrast greys as background-color by making disabled buttons inverted grey text on white and at the same time inclining contrast of enabled normal and quiet buttons by using #222 as text color.

Comments? Thoughts?

Maybe this isn't the right question at all. What is the point of disabled buttons? What if using them is not something we should be doing in the first place?

Keep things simple. If an item isn't relevant, why show it at all? If a disabled item includes something important that users need to see, maybe it shouldn't be disabled, or the information should be somewhere else.

I dunno if this actually works in practice, but it might be worth looking at the current usages of disabled buttons/items and considering if it really is the best approach.

Maybe this isn't the right question at all. What is the point of disabled buttons? What if using them is not something we should be doing in the first place?
Keep things simple. If an item isn't relevant, why show it at all? If a disabled item includes something important that users need to see, maybe it shouldn't be disabled, or the information should be somewhere else.
I dunno if this actually works in practice, but it might be worth looking at the current usages of disabled buttons/items and considering if it really is the best approach.

State is dynamic. A "proceed" button shouldn't be enabled if the user cannot (e.g. validation errors), but should become enabled once they can. Thus there needs to be a visual way to express to the user the differentiation of statuses between "I can use this" and "I cannot".

State is dynamic. A "proceed" button shouldn't be enabled if the user cannot (e.g. validation errors), but should become enabled once they can. Thus there needs to be a visual way to express to the user the differentiation of statuses between "I can use this" and "I cannot".

Why? Forms often don't make that distinction, but users don't generally expect the submit button to do anything when there's nothing to submit, either. And even if we are making the distinction, do we really expect users to know the difference between two arbitrary button styles when they may not have seen either before?

Disabled elements are a pretty new thing, which have become common in design in general without people putting much thought into them. They might be good and well-worth it, but they might also just be a random fad introducing more problems than they're worth. Either way, the thought needs to be there.

Disabled elements are a pretty new thing, which have become common in design in general without people putting much thought into them.

Bold claims need strong evidence. I've been using forms/dialogs in GUI systems with disabled buttons since the early '90s.

I mean in web forms. Previously there was simply no way to do it because implementing/restyling forms in js was so poorly supported across browsers.

Either way, though, the question stands. Is it good? Does it work here, and are we using it right when we do? https://meta.wikimedia.org/wiki/Grants:Project/Rapid/Apply makes me wonder, since it's kind of obvious those aren't going to do anything without actually entering something. But there are probably other things where it does make more sense, and perhaps it's also not as important that they be legible ahead of time. Perhaps they're fine as is, and the previous contrast fix was enough. Or perhaps not.

What is the point of disabled buttons? What if using them is not something we should be doing in the first place?

E.g. a settings panel without 'save' button: users expect the options to be saved in real time; settings panel with disabled 'save' button: users know that they'll have to click the button in order to save the options.

E.g. a settings panel without 'save' button: users expect the options to be saved in real time; settings panel with disabled 'save' button: users know that they'll have to click the button in order to save the options.

Better example there might be having the save button disabled as long as nothing's changed, or re-disable itself if they put their settings back in order to show them whether or not there's anything different there. This is especially useful in situations where actually submitting the change can cost something; where there's the reasonable option to just save everything automatically without using a button at all, having it disabled or not it probably isn't going to add much.

Volker_E claimed this task.Aug 19 2016, 8:00 PM
Jdforrester-WMF lowered the priority of this task from High to Medium.Sep 7 2016, 5:39 PM
Jdforrester-WMF lowered the priority of this task from High to Medium.
Jdforrester-WMF moved this task from Reviewing to OOjs-UI-0.17.9 on the OOUI board.
Jdforrester-WMF edited projects, added OOUI (OOjs-UI-0.17.9); removed OOUI.

Change 309483 had a related patch set uploaded (by VolkerE):
MediaWiki theme: Enhance button styles and align them to new color palette

https://gerrit.wikimedia.org/r/309483

Volker_E updated the task description. (Show Details)Sep 9 2016, 7:00 PM
Jdforrester-WMF closed this task as Resolved.Sep 9 2016, 11:50 PM
Jdforrester-WMF removed a project: Patch-For-Review.

Change 309483 merged by jenkins-bot:
MediaWiki theme: Enhance button styles and align them to new color palette

https://gerrit.wikimedia.org/r/309483