(Accessibility) The contrast ratio of input fields border is below the WCAG threshold

[morhof]

WCAG successs criterion 1.4.11 - Non-Text Contrast - AA

Steps to reproduce

1. Click on Dashboard
2. Click on Search field

Actual Result

The following contrast ratios of interactive elements do not conform to the minimum contrast requirements of 3:1. Therefore, these elements are more difficult to perceive, and may be completely missed by users with low vision:
Borders of checkboxes 1,2:1

Expected Result

Between foreground and background, the minimum contrast ratio should be 3:1

Meta Issue
n.a.

Kibana Version:
8.11.2

OS:
Microsoft Windows 11 Enterprise 64bit
22H2 (10.0.22621.3007)

Browser:
Chrome Version 121.0.6167.140

Screen reader: [if relevant]
n.a.

Relevant WCAG Criteria: WCAG success criterion 1.4.11 - non-text contrast - AA https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html

Relevant ARIA spec:
n.a.

[elasticmachine]

Pinging @elastic/kibana-accessibility (Project:Accessibility)

[elasticmachine]

Pinging @elastic/kibana-presentation (Team:Presentation)

[elasticmachine]

Pinging @elastic/eui-team (EUI)

[1Copenut]

Thank you @morhof for filing this issue. We've been discussing and do feel this is an area for improvement. My colleague has filed an improvement ticket in our EUI design system repository to improve form input contrast. After that fix is integrated into EUI, it will be folded into a future release of Kibana.

[elasticmachine]

Pinging @elastic/appex-sharedux (Team:SharedUX)

[petrklapka]

@Dosant - would you consider this a good first issue for our new hires?

[cee-chen]

This would not be a good first issue - it needs to be handled at the EUI level, not in Kibana, and we've received pushback from designers when increasing the contrast ratio that makes it not a simple change (but instead something we likely need to create a high contrast mode for in EUI's theming).

See elastic/eui#7509 (comment) for more / to track this effort

[JasonStoltz]

This would not be a good first issue - it needs to be handled at the EUI level, not in Kibana

Just to clarify, the current plan is that the Shared UX team will update the specific Kibana instances mentioned in this ticket. We may not be able to wait for a more wholistic EUI fix.

[Dosant]

Here is how those UI elements would look like if we'd override the color to make the contrast pass. For this I increased the color opacitiy until the needed contrast is reached rgba(32,38,47,0.1) -> rgba(32,38,47,0.5) (same color, but increased opacity)

Maybe there is a nicer override we could find that would pass the test, but since this override breaks consistency and not aethetically pleasing, maybe we could at least only apply it for users with prefers-contrast setting?

Please suggest how to proceed.

[JasonStoltz]

Maybe there is a nicer override we could find that would pass the test, but since this override breaks consistency and not aethetically pleasing, maybe we could at least only apply it for users with prefers-contrast setting?

I guess there's two aspects to consider here:

1. From a design perspective, would this be better hidden behind a prefers-contrast setting? - I'm sure product/design would have an opinion, but I'm guessing the answer would be yes, that's ideal. It could be weird to have this only applied to certain parts of the UI. This seems like the most unobtrusive means of solving this problem.
2. From an a11y perspective, if we're putting this behind prefers-contrast, does that still meet WCAG and customer expectations?

Are there other parts of the UI that we're planning to apply this same sort of one-off contrast fix to as well?

FWIW, this is essentially what we've proposed in our High-Contrast variant of EUI.

If we were to eventually implement this EUI proposal, it would evolve nicely from the one-offs you're doing now (using darker borders behind a media query) to the whole product using the same strategy.

It'll be important to track these one-offs until then so we can replace them.

Also, for awareness, we'll definitely need to test this with the new theme once that lands to make sure these overrides still work. That's one tricky part with the media query, it's easy for folks to forget to test.

UPDATE:
I wonder if we could combine the EUI proposal above with what you're trying to do in one-offs here a bit. Thinking out loud ... I wonder if we could essentially introduce the High Contrast mode to EUI from our proposal, but limit it's usage to just targeted places in Kibana for now. Meaning, perhaps you could wrap sections of code like this with a theme override to force high contrast support. Something like:

<EuiThemeProvider highContrast={true}>
  <your code here>
</EuiThemeProvider>

It kind of lets us ooch into high-contrast mode without fully buying into it for the entire UI.

Meaning, you could wrap that around targeted code in Kibana and it would get darker WCAG compliant borders based on the prefers-contrast media query.

Does that make sense? I feel like I'm on to something here but need @cee-chen for additional thoughts or input.

[cee-chen]

Meaning, you could wrap that around targeted code in Kibana and it would get darker WCAG compliant borders based on the prefers-contrast media query.

Just to clarify - I've already baked in detecting this media query to elastic/eui#8036. So if we implement high contrast mode in EUI, all users who have that setting on will see higher contrast borders across all EUI components. If we don't want this, I'll need to turn it off in my PR.

Otherwise, adding <EuiThemeProvider highContrastMode={true}> wrapper around specific components you want to test (but not the entire app) should work.

[JasonStoltz]

Hey @petrklapka, just let us know if this is something you'd like to pursue.

[petrklapka]

Hey @JasonStoltz @cee-chen @Dosant !

Anton just explained to me how this "prefers-contrast" setting works. I love the idea of the user setting this in the OS (it is available both on Mac and Windows), and our theme adapting to it. Why not just do this? Why "ooch" into it like Jason said above?

Here is what I propose:

Let's not enable it on the OS level YET. Let's use Cee's PR but enable it as a User Setting (like Dark Mode) for the first iteration. That will let us call it an experimental feature and test it ourselves and get user and auditor feedback. After WE are comfortable with it, we remove the experimental feature label, and we also enable "Use OS Setting" as an option for High Contrast.

To Jason's questions:

1: From a design perspective...

I want to move on this, and not make it into a long comittee discussion. If we enable it as a user setting like dark mode, and include a warning that it is experimental, we can quickly help our A11Y users, while giving ourselves time to fully audit the impact of the High Contrast mode that Cee already has ready to go. I would rather ask forgiveness than make this into 3 month asking for permission.

2 From an a11y perspective, if we're putting this behind prefers-contrast, does that still meet WCAG and customer expectations?

Yes. That is why I think we should just do this and not make a big stink about it. We are not changing any design, we are just exposing something alternative and helpful.

[petrklapka]

@Dosant and @cee-chen - Jason and I chatted and we're agreed to the above approach. Anton, after Cee and EUI do their bit, can you do a POC of this for the next demo day after it becomes possible? This should be pretty easy to get traction with.

[JasonStoltz]

Hey @cee-chen. Any idea how much much effort it would take to cleanup and productionize your PR?

Let's make the API flexible enough so that Petr can use whatever approach he wants in regards to a UI toggle vs media query vs both.

[cee-chen]

Hey @cee-chen. Any idea how much much effort it would take to cleanup and productionize your PR?

Probably a week or so! I can switch to it starting next week / after some EUI+ cleanup work.

[tsullivan]

I'll take over this issue from Anton on the SharedUX side. I've caught up on the thread and see these as my next steps:

1. Wait for the EUI changes to land.
2. Add a new Advanced Setting for high contrast mode
3. Pass a highContrastMode prop to EuiThemeProvider which will have a value based on the new setting.
4. Test/Audit/Demo :)