Even worse for frameless buttons:

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?

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

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

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.

In T88038#2321569, @Isarra wrote:

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".

In T88038#2321579, @Jdforrester-WMF wrote:

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.

In T88038#2321594, @Isarra wrote:

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.

In T88038#2321569, @Isarra wrote:

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.

In T88038#2326235, @Ricordisamoa wrote:

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.

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

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

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