Darken input borders to meet minimum contrast for UI components

[gcamacho079]

Description

Inputs (text, radio, checkbox, etc.) should meet 3:1 color contrast against page background per 1.4.11: Non-Text Contrast. This PR introduces a new CSS variables for input border and input border color to manage field borders throughout the control panel.

Related issues

Resolves DEV-515, DEV-322, DEV-317

[linear]

DEV-515 Radio button and checkbox field borders have insufficient contrast against background

The border for these elements is under 2:1 against the white form background

These element borders should be darkened so that they meet the 3:1 contrast ratio prescribed for user interface components

Screen Shot 2022-04-18 at 12.16.37 PM.png

Resolves CMS-162

DEV-322 Text inputs without placeholder text do not have a high enough contrast ratio against the background

Screen Shot 2022-03-14 at 3.19.04 PM.png

When text inputs do not have placeholder text, their borders do not meet contrast requirements for non-text content. The current contrast ratio is 1.58:1 on white backgrounds, and 1.24:1 on the global gray background.

The color should be changed to a blue of #688aac to be a dark enough outline on all backgrounds.

Resolves CMS-041

DEV-317 "Keep me logged in" checkbox doesn't meet minimum contrast guidelines

The contrast of the checkbox outline against the page background is 1.74:1. This should be darkened to achieve a contrast ratio of 3:1 for graphical user interface components

CMS-038

[brandonkelly]

That feels really harsh to my eyes. Would it be OK to only do this for prefers-contrast? Otherwise, maybe via a new accessibility preference?

[gcamacho079]

That feels really harsh to my eyes. Would it be OK to only do this for prefers-contrast? Otherwise, maybe via a new accessibility preference?

After some additional research, a new accessibility preference sounds like a good idea for this change, as high contrast modes can have usability implications for some users. However, we do have to ensure that the path to enable this setting does meet minimum contrast requirements. This path includes:

1. Login page
2. Opening the My Account menu
3. Clicking the link to go to preferences
4. Going to the Preferences tab
5. Enabling the high contrast setting

I like your idea of having a preference versus using prefers-contrast as some users might not even know how to change their contrast settings, and browser support could be variable.

I’ve created #12517 to ensure the Account menu meets the minimum contrast for UI components; however, if we’re using a checkbox-style option (i.e., “Enable high contrast mode”), checkbox borders would still need to be darkened. Thoughts?

[brandonkelly]

Think this goes back to coming up with some sort of account setup wizard, which could be presented to users when they first log into the control panel, which presents them with all the accessibility preferences. Accounts can default to having any relevant accessibility settings enabled by default to ensure the wizard meets the necessary criteria.

[brandonkelly]

So for the purposes of this PR, let’s just add the preference and not worry about whether the screens leading up to it are compliant.

[gcamacho079]

@brandonkelly user preference added! For simplicity, I reverted some changes to remove the extra --input-border variable. I thought having too many stylistic/layout changes tied to the higher contrast view might be difficult to maintain, so I retained the changes I made in the .meta container for all users, so there’s now a faint border around (and spacing between) inputs in this area for low-contrast users.

[gcamacho079]

@brandonkelly I was revisiting this PR about disabled element contrast inside indexes. I wonder if this “Increase contrast” setting would be a good candidate for looping in the "disabled elements get italicized text” update. To clarify, we can create some accessibility documentation in the docs that outline all the UI changes bundled with that user setting; this would also help us achieve the ATAG requirement for documenting accessibility features.