Input borders should meet the WCAG AA contrast ratio requirements

[tkajtoch]

Describe the problem

According to the recent kibana issue EUI input fields borders have contrast ratios below 3:1 and don't meet the WCAG AA contrast ratio requirement.

The same may apply to other components like EuiTextField, EuiSearchField, EuiSelect, and more.

To Reproduce

Go to https://eui.elastic.co/#/forms/form-controls#text-field and measure EuiTextField border contrast ratio.

Environment

• Operating System: MacOS 14.2
• Browser: Chrome 121
• Environment: production

Proposed solution

Increase affected components' border contrast ratios to 3:1 or above.

Screenshots or Trace Logs

[cee-chen]

Worth noting: the password component is dark enough to pass the contrast check - why is it a one-off?

[kyrspl]

@cee-chen

Worth noting: the password component is dark enough to pass the contrast check - why is it a one-off?

I noticed that this is true when the dual, or preppend or append parameters are set to true. It seems that this happens because the background of these added elements use a lighter gray (which is the same as the field's border)

[JasonStoltz]

When this is finished, we'll need to update and verify elastic/kibana#176219

[1Copenut]

I'd recommend reading through Understanding SC 1.4.11: Non-text Contrast (Level AA) for inspiration. There's a lot of visual examples of how the 3:1 contrast ratio for non-text elements can be accomplished. This will probably result in form inputs that look "heavier" because of the increased saturation of the border, but that's a trade-off we'll have to make. Whatever colors are settled on, we can quickly retest locally in PR for light and dark mode compliance.

[JasonStoltz]

It looks like the solution is to simply increase the contrast of the border around these inputs. I think the solution is relatively straight-forward. I think we could probably spike something out and deploy it to a test environment and have @kyrspl and @MichaelMarcialis review it.

I couldn't find where exactly in the code we apply it but it appears to be a box-shadow.

I think the level of effort here is relatively small but verifying it in Kibana properly will probably take a little extra time.

[1Copenut]

@JasonStoltz Looking at this a second time, we'll need to consider the border on additional items including:

• Button groups in forms
• Filter groups
• Inline edit

I'm probably missing some, but the gist is these gray elements with a shade darker gray border or separator should be part of this work.

[kyrspl]

@1Copenut - Regarding buttons --> How should we interpret the contrast requirement of text vs background color?
Are we compliant with the contrast of text alone or do we also need to increase contrast with the border/background as well?

[1Copenut]

@kyrspl WRT buttons, as long as your text is 3:1 to the background, you'll be in compliance. The button groups I was looking at has a border color that's approximately #EAE9E8 which works out to a contrast ratio of 1.21:1 with the white background. That's the metric I'm interested in, bumping that to 3:1.

[cee-chen]

#7930 has a spike of this work if y'all would like to review the changes here:

• Form controls
• Button groups in forms
• Filter groups
• Inline edit

[cee-chen]

@1Copenut Question, does EuiSelectable also now require a border at all times, with increased contrast? https://eui.elastic.co/pr_7930/#/forms/selectable

[1Copenut]

@cee-chen

Question, does EuiSelectable also now require a border at all times, with increased contrast?

Yes, I believe it does. It's got the same light gray border and divider between options so would fall under the same non-text contrast requirement.

[JasonStoltz]

We've done some investigation on our side. The effort required here to meet the 3:1 contrast requirement for all inputs in Kibana is quite large. The challenges are as follows:

The scope of core changes to EUI

On the EUI side, we would need to update all of our interactive elements: so not just text inputs as mentioned here, but also buttons, select components, icon button, panels that act as buttons, and I'm sure there's more I haven't mentioned here. It's not just about borders, we also need to consider things like secondary buttons that use a light shade as their background with no border, or components like EuiEmptyButton, which use no background or border at all.

In order to proceed we'd need a complete list of changes required at a per-component level.

Ripple effects in Design

Increasing contrast of input elements changes the look and feel of the entire design. Quite frankly, the interface stops looking, feeling, and working as intended with dramatic contrast changes to interactive elements.

In order to proceed, we'd need to re-evaluate the entire design of EUI and Kibana to account for these contrast changes.

Interactive elements outside of EUI

Changing EUI (by my rough estimate) may solve this issue for 50% to 80% of Kibana. However, there are many interactive elements that are created independently in Kibana outside of EUIs control.

In order to proceed, there will need to be a concerted effort to udpate the remainder of interactive elements in Kibana that are outside of EUI.

Risk to adoption

If we were to proceed with updating our theme to be compliant with SC 1.4.11, there is a high likely-hood that we will get pushback from our core product and design stakeholders. This is a dramatic change and the overall end product may be perceived as a degradation in overall design quality.

To proceed, we need to consider whether or not this would be a change to our core theme, or whether this could be implemented as an opt-in high-contrast user setting.