This is the expected UI, we've been simplifying and flattening the button states and colors. The outline style is used in more auxiliary/optional elements vs. solid for submits. These will fit more into the upcoming full redesign.

https://secure.phabricator.com/uiexample/view/PHUIButtonExample/

It's an accessibility issue:
http://webaim.org/resources/contrastchecker/

Foreground color: #2980b9
Background color: #daeaf3
Contrast Ratio: 3.49:1

Normal Text
WCAG AA: Fail
WCAG AAA: Fail

Large Text
WCAG AA: Pass
WCAG AAA: Fail

WCAG 2.0 level AA requires a contrast ratio of 4.5:1 for normal text (14 point and bold or larger) and 3:1 for large text (18 point or larger). Level AAA requires a contrast ratio of 7:1 for normal text and 4.5:1 for large text.

Note btw, that this is by far not the only problem in phab. The blue grayish 'via web' on this page is also really problematic.

Foreground color: #8c98b8
Background color: #eee
Contrast Ratio: 2.48:1

Normal Text
WCAG AA: Fail
WCAG AAA: Fail

Large Text
WCAG AA: Fail
WCAG AAA: Fail

Our base colors are all client side variables, and aren't (for the most part) stored in the CSS. I'd rather build a stylesheet generator for installs that need to provide alternate states, like high contrast, larger fonts, etc, than to try to solve these problems all as one offs. Looking that the links you provided, #444 is the "lightest" grey we could be able to use in any design, so we'd have to give up quite a bit. If your install has needs for this feature, please follow T4213.

We're also going under a near-full redesign, see the Roadmap, and can assure you the grey background is going away globally.

Yes gray is terrible for accessibility and gray on gray should be avoided at all cost (and for some reason designers love this :) ). (Dark gray on (near) white however, can very much increase readability enjoyment compared to black on white)

Do remember that WCAG compliance might affect your eligibility as a government contractor (if you are interested in such things from a business perspective). Besides that, I'd say that when looking at things like this, you just have to think it a bit through. For instance, this was reported about the buttons, but in my opinion as "wikimedia's accessibility volunteer" (just made that up), the "New task created. Create another?" part is actually much worse.

Reasoning:

• The text of the button is bold (huge plus)
• The buttons have the border (creating visual separation) probably gives you enough feedback to indicate that something is a button.
• Buttons are UI elements. They are succinct and don't require reading text for a longer time. Additionally, they are consistent elements, once you have read it the first time, your 'muscle memory' will start kicking in, so the reading strain is likely not very continuous.
• When you hover, you get a white background, making it very readable (not that this helps you much on mobile).

The note however:

• is not bold
• is a bit longer text
• being free flow text instead of a button, will probably make your mind read it every single time (it's a message, our mind is trained to expect it to be more variable than other UI elements)
• has no alternate view state.

For "Via web", you could say: What are you missing if you are not able to read that ? (Opposed to this, you could argue that people will try to read it anyways, and that this creates 'strain' to them).

The WCAG criteria should always be evaluated considering their intent, and the raw criteria do not always map on a real situation, that is still enjoyable for the majority of users, so I'm not a hardliner on WCAG criteria myself.

Now the WCAG criteria have 2 grades (AA/AAA) for 2 sets of text. 'normal' and 'larger' (small is already forbidden by default, which probably makes about every textual element fail right now anyway, but increasing font size is rather easy for UAs these days) and they also mention bold. If you interpet that a bit more, forgoing 'compliance', you could say:

• Smaller text should have higher contrast
• 'Surface area' (bigger or fatter fonts) of the text increases readability.
• You want to be as close to the advised ratio's as possible.

So for this blue message on blue background you might want to consider:

• Having 2 foreground colors for two sets of fontsizes
• Requiring bold on this type of foreground/background combination
• Choosing a different font that is 'bigger/fatter'
• Making the background slightly lighter
• Just change that situation to require black text.

If you want to put full responsibility with 'skin developers', you could also consider making 'contrast indicators' that will alert theme developers that they are making less readable choices...
For Wikimedia, we are experimenting with colorblindness simulation for our new Living style guide: (See the glasses dropdown on: http://livingstyleguide.wmflabs.org/wiki/Main_Page )

Just some thoughts..

There are a few things here than come to mind.

• The design here for this note specifically, is a "minor" note. It is a note that is neither important, nor needed in the day to day flow of a persons work.
• The act of creating multiple tasks is more of an operation we expect from more experienced Phabricator users, who are just looking for the button.
• The previous design for this bar was actually more hidden in my opinion at least, as it had no color and was tucked under the main header. This new design gave it more prominence.
• The blue/blue note style is currently only for "minor" notes, "major" notes sit above and have more contrast in their text. This was recently redesigned (additional contrast). We had previously used blue/blue for all notes for several years. I don't recall any actual use issues.

I don't disagree really with any of your individual points, in isolation it's easy to see them. But there was intention in the current design, that this is a note of minor importance attached to an object box.

That said, I expect the redesign to significantly change the current display of notes, especially given new object boxes that are coming. Let's just agree that your feedback will be kept in mind.

If you are interested in modifying these locally, the variables are here: https://secure.phabricator.com/diffusion/P/browse/master/src/applications/celerity/CelerityResourceTransformer.php;78438951c804e3ec184a839d8f96741146a21dd4$172

After updating, you'll want to re-run celerity to build the packages: bin/celerity map.