The button is T88038.

I've added a screenshot to the description, and clarified the other separate bug.

I agree that the disabled editing tools are probably too low in contrast (#CCC on a white background).
I believe the low contrast is coming from this:

.oo-ui-listToolGroup.oo-ui-widget-disabled .oo-ui-indicatorElement-indicator, .oo-ui-listToolGroup.oo-ui-widget-disabled .oo-ui-iconElement-icon {
    opacity: 0.2;

and

.oo-ui-listToolGroup.oo-ui-widget-disabled {
    color: #CCC;

and related classes.

I don't think we have good inhouse guidelines for this, yet.

In T89271#1032516, @Aklapper wrote:

And what is the need to distinguish them if they are all disabled anyway? :)

The need to distinguish them, is helpful when learning about an interface, or when wondering "what the hell is that line which my poor old eyes cannot read?" eg.

FYI, currently being discussed here T109915

Regarding what quiddity said, there's a problematic balance that needs to be found between making things clearly disabled (especially when by themselves) and also legible. The problem is when they're consistently legible due to sufficient contrast, they tend to also stand out enough to not look disabled, especially if grey is used elsewhere in the interface anyway.

In conclusion: you might be doomed.

Or you need to be more creative and come up with some other distinction.

The problem is when they're consistently legible due to sufficient contrast, they tend to also stand out enough to not look disabled

This is very true. When everything is in focus, nothing is in focus.

We'll try to find out what works *best.* It's challenging, sometimes impossible to cater to all. Perhaps this is where T91201 becomes helpful and why it's necessary to have such setting.

Perhaps it could be partially solved with a mouseover color change? Currently, if I mouseover the disabled elements in the VE toolbar (e.g. "Clear styling") nothing changes.
(Click "View file" for a screencast: F2656676 )

I can't see the screencast even when I click "View file"

We also thought to change the cursor: not-allowed over a disabled link. But there's no mouseover on mobile.

@Quiddity The very inherent functionality in a disabled item (button, widget, etc.) in basically any major evolved UI platform is that it does never change a bit, it's not selectable, not focusable -- purely no interaction possible at all, just grayed out.
Inventing an interaction might mislead/confuse much more people as it would help the small group who has problems to see what kind of disabled element they are facing.

We're talking about using #888 for inactive elements in this task.

ping @Quiddity @Elitre, want to make sure I get your thoughts in before we close the task next week!

In T89271#1891365, @violetto wrote:

ping @Quiddity @Elitre, want to make sure I get your thoughts in before we close the task next week!

#888 looks good to me, and I agree with you and Volker's concerns about my previously suggested idea.
(I do wish the WCAG had clearer guidelines about disabled elements. :-( I grok that the difference in contrast between black and #ccc is more intuitive, for most users, but I don't know how else to approach the problem, until we have Accessibility settings that can override this type of thing (esp. for anon-users).)
Thanks again, for all your overall work on this. :-)

@Quiddity I'm still not 100% convinced by #888, but for the time being, it might be our best compromise before we either receive negative feedback by users or have large user testing done.
Adding to my comment earlier, in best accessibility practice, color shouldn't be the only method of conveying important information. So we are also trying to make sure, that things like cursors and patterns are changed, without interfering productivity. In the mid-term accessibility settings would be a useful way to go forward.

#888 works more in favor for the old monitor users and users with vision deficiency. The contrast between black and #888 is quite distinguishable, and yet borderline illegible in the eyes of WCAG 2.0. Until we get T91201 in as a priority, this sounds like the best we can do for the time being, although it's a compromise for both sets of users.

On top of #888, I'm also proposing a not-allowed cursor over disabled links (see the prototype here), but this only works on non-mobile and tablet screens.

Even W3.org did not follow the guidelines! This isn't the end of this issue though, we're keeping an eye out of WCAG guideline changes make iterate our solution as they evolve.

@violetto Would you give an image example of #888 applied like in the comment of @Quiddity above?

Just for completion: #949494 is the furthest from #000 gray that passes Level AA (18pt) at contrast ratio of 3.03:1

http://jsfiddle.net/zL41byxk/2

I actually meant a picture in here, because the jsfiddle might change (given its link to the github project) or getting abandoned at some future point and our discussion process might then not be fully reproducible any more.

Have opened related T121960: Use `not-allowed` cursor for disabled elements within WMF products

In T89271#1891535, @Quiddity wrote:

In T89271#1891365, @violetto wrote:

ping @Quiddity @Elitre, want to make sure I get your thoughts in before we close the task next week!

#888 looks good to me, and I agree with you and Volker's concerns about my previously suggested idea.
(I do wish the WCAG had clearer guidelines about disabled elements. :-( I grok that the difference in contrast between black and #ccc is more intuitive, for most users, but I don't know how else to approach the problem, until we have Accessibility settings that can override this type of thing (esp. for anon-users).)
Thanks again, for all your overall work on this. :-)

Ditto, please close this when you're ready :)

Yikes, I just noticed your message @Volker_E, feel free to attach the image next time without waiting on me!

@Elitre @Quiddity @violetto I need to reassure one more time, before putting this into patch sets. I'm critical, that a change as strong as moving from #ccc to #888 might result in regressions as non-affected users might be mislead by not clearly differentiate between active and disabled states – especially when T121960 is not implemented side-by-side.

• Firefox uses #979797 for its disabled UI elements (ex: Preferences settings in recent versions)
• Google Style Guidelines say "disabled text have even lower visual prominence with an opacity of 38%." which with #000 as base color would result in #9e9e9e
• Apple doesn't seem to have guidelines on disabled text in their Human Interface Guidelines, but disabled text in Finder and file dialogs (in 10.11) is #858585, for button icon outlines its far #bfbfbf
• Microsoft is not providing lot guidelines considering disabled elements, the only recent one featuring a disabled button fails WCAG level AA miserably with a text color of #a4a4a4 and background #ccc resulting in a contrast ratio of 1.55:1

I would like to play it a bit safer with #949494 and contrast ratio of 3.03:1 – resulting in a major improvement over current 1.61:1 with #ccc.
Do you agree with my points and my resulting proposal?

That seems reasonable to me. Thanks for the research. :-)

Lighter is better for users who aren't vision deficient. We are only WCAG AA compliant with large text with #888, and with #949494 we won't be compliant with any standards. But at the same time, use case must be sparse with disabled large text. I'm pretty unaffected by this suggestion because the difference is small:

But what does @Elitre @Isarra @Dodoiste @RexxS think?

@violetto Thanks for your inputs and the image. Just as small correction: #949494 is WCAG AA compliant with large text, see my comment above.

Being furthest away from #000 gray was one perspective. I also compared it with the backgrounds we'll be using in the palette because UI components can be found in many different layers of an interface aside from #FFF. The examples are shown here and listed here:

#F9F9F9
#EBEBEB
#DADADA

I used webaim's color contrast checker tool.

Just a reminder that contrast isn't just for bad eyes - it also applies to bad screens, which can also render different colours into the same thing. Not saying it'd necessarily be an issue here, but in general it's good to keep in mind, since it's unaffected by size etc.

(I'm not a blocker in this conversation, any improvements from the screenshot I provided would work for me.)

If we want to keep the disable elements in the accessible range of colors (so that content can be read anyways), we may want to communicate that they are disabled to those users that may not realise at first sight these are disabled.

In the same way that we increase the contrast of interactive elements on hover, we can consider decreasing it for disabled elements on hover. I guess that going to a lower contrast than AA once you hover on a disabled element can be acceptable and draw less attention than the "forbidden" cursor (T121960).

Disabled elements are basically non-interactable UI elements. Our intention of decreasing contrast on hover might feel like a bug because the button reacts to the cursor, but it's going out of focus/becoming lighter. But on the other hand, if it does not look disabled, we will frustrate users with this non-responding UI element. Like someone mentioned in task T121960, Bootstrap also has been using the not-allowed cursor. Perhaps it's worth doing some research to see how have that been received?

Want to point out also that we plan to underline interactable links as much as possible at least on interaction (see screenshot below from M101)

Disabled links must look disabled on its own, but I wonder if disabled links do not underline on interaction, if that is enough to show that it's a disabled link? But this assumes the user has already interacted with interactable links in the past.

In T89271#1922397, @Volker_E wrote:

(...) I'm critical, that a change as strong as moving from #ccc to #888 might result in regressions as non-affected users might be mislead by not clearly differentiate between active and disabled states – especially when T121960 is not implemented side-by-side.

(...)

I would like to play it a bit safer with #949494 and contrast ratio of 3.03:1 – resulting in a major improvement over current 1.61:1 with #ccc.

I like this, and I agree that #888 would be too dark. We use #555 for regular button text… Maybe we should change that to something darker.

Looking at this task, I'm guessing you're proposing this for text color only (that is, #949494 on white background). Are we changing anything for the case of background color being used to indicate disabledness? (Right now, it's white on #ddd.)

We use #555 for regular button text… Maybe we should change that to something darker.

Btw, we've decided in task T109915 (prototyped here) to use #222 instead of #555 for UI text.

Change 310346 had a related patch set uploaded (by VolkerE):
MediaWiki theme: Align disabled text contrast to WCAG compliance

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

Change 310346 merged by jenkins-bot:
MediaWiki theme: Align disabled text contrast to WCAG compliance

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

With our newly improved color palette M82 we are featuring #72777d on disabled elements, which passes level AA in color contrast web content accessibility guidelines and is intended to solve this issue by clearly improving the contrast over the status quo back when this task was filed.

Overhauled toolbar with disabled element:

Happy to hear your feedback, @Elitre

WFM, FWIW.