[Lens] improve metric contrast with default status palette

[drewdaemon]

Kibana version: 8.7 back to 8.4

We default to using the EUI "status" palette when color-by-value is first enabled on a metric vis. We received internal feedback that the default green makes the metric text a bit hard to read. Do we agree (look at the metric in the top left)?

Does it make sense to

• Update the palette?
• Strengthen the contrast algorithm?
• Use a different palette by default?

cc @P1llus, @gvnmagni

[elasticmachine]

Pinging @elastic/kibana-visualizations @elastic/kibana-visualizations-external (Team:Visualizations)

[stratoula]

@markov00 this comes automatically from the EC, right?

[gvnmagni]

I personally agree, I believe we are using the standard EUI status palette but I always found that a little too dark for our case. I think we already have a couple of alternatives:

1. to use the "behindText" palette and pick the green, yellow and red color from that.
2. to use the warning/success/danger colors from Elastic palette

So that the result would be the following:

[dej611]

Strengthen the contrast algorithm?

This has been discussed multiple times in the past. The algorithm is the standard one and even if it provides some sub-optimal result in some context, it is designed to work in a much wider accessibility scale.

[markov00]

Exactly @dej611, this, unfortunately, pass for the WCAG AA color contrast check.

The APCA instead (will replace the current color contrast check in WCAG 3.0) shows clearly that the font size should be at least 62px with a normal weight to be accessible with that background color.

where instead a white is preferable with a smaller font size.

Unfortunately, the WCAG 3 is still in draft, and we can't be compliant with WCAG2 if we don't have at least one theme that is aligned with WCAG2 color contrast.

The ways are multiple:

• provide different palettes
• forget about WCAG2 and align with APCA algorithm
• both of them

[gvnmagni]

there is a little caveat though, our text is not full black and we pass only the AA check for large texts. If we move to one of the two lighter versions that I was proposing we are getting better at that

[dej611]

I would just leave this here 😄 https://github.com/elastic/kibana/pull/81776

[markov00]

@gvnmagni can we double-check how it will look like if we use text-shadow or text-stroke to avoid these low contrasts? As Marco linked above we already worked on something like that with bar values and Maps already works with that.WDYT?

[gvnmagni]

I am not an expert in accessibility but I guess that it would probably solve the contrast issue. On my side, I am not a big fan of it since it impacts heavily on the aspect of the component. I think it works fine when we have small numbers but in this case we have also strings of texts and I don't like that effect too much on texts honestly. Also, would that apply to the icon as well?

Why can't we simply adjust the status palette and make the 3 colors slightly lighter so that it's more readable and also beautiful? that would be a win-win 😊

[stratoula]

Yes I agree with @gvnmagni, I know that @dej611 is a fan but I am not a fan either (although I agree they are effective!) Moreover when we had applied them on bar charts labels, many users preferred to use vislib instead.

[markov00]

I prefer to move to APCA color contrast check, it will probably solves 99% of the cases with no changes in colors/style etc. I will double check with the accessibility team if we can do this switch now