Consistent status styling for form inputs

[natalia-fitzgerald]

Proposal

Background

In the CFPB Design System the current approach to hover and focus colors is inconsistently implemented. For some inputs we mirror status colors for status state hover and focus and for others we use Pacific. Here's an audit of the current state with visuals: https://github.com/cfpb/design-system-react/issues/357

I would like to propose and implement an update. The goal of this update is to increase consistency, reduce the maintenance burden, implement state and status styling across components, and make our form inputs more usable.

Implementation details

• Hover and focus styling is Pacific regardless of status
• Show status colors (2px Green, Gold, Red) on enabled only.
• Once a user starts interacting with the field - hover, focus, clicking, typing, the field gets the Pacific coloring.

Checkbox	Single select

Status	Base	Hover	Focus
Enabled	Border: 1px, Gray 60 (#919395)	Border: 2px, Pacific (#0072ce)	Border: 2px, Pacific (#0072ce) and Outline: Dotted 1px, Pacific (#0072ce)
Disabled	Border: 1px, Gray 60 (#919395) and Background: Gray 10 (#e7e8e9)	Cursor change	None
Success	Border: 2px, Green (#20aa3f)	Border: 2px, Pacific (#0072ce)	Border: 2px, Pacific (#0072ce) and Outline: Dotted 1px, Pacific (#0072ce)
Warning	Border: 2px, Gold (#ff9e1b)	Border: 2px, Pacific (#0072ce)	Border: 2px, Pacific (#0072ce) and Outline: Dotted 1px, Pacific (#0072ce)
Error	Border: 2px, Red (#d14124)	Border: 2px, Pacific (#0072ce)	Border: 2px, Pacific (#0072ce) and Outline: Dotted 1px, Pacific (#0072ce)

Affected components:

• Checkboxes
• Multiselects
• Radio buttons
• Single selects
• Text inputs
• Text area inputs
• (maybe) Date picker

For the purposes of this initial effort we would prioritize the components which appear in the data submission platform:

• Checkboxes
• Multiselects
• Single selects
• Text inputs
• Text area inputs

Related questions

Another question I have, which is out of scope but related, is whether we may want to consider applying this approach (Pacific hover and focus) to other interactive elements, like buttons and links. But as a first step I'd like to confirm that this approach is appealing to the team and if so we will begin to update the input components that appear on the data submission platform first.

Related issue:

https://github.com/cfpb/design-system-react/issues/357

@sonnakim for awareness

[natalia-fitzgerald]

Yesterday I discussed this approach with @sonnakim, @anselmbradford, @itsmedavep . Coming out of that conversation I thought maybe some mock-ups of all of the possible approaches would create a reference point for our discussion.

Here are the 4 possible approaches

• Approach 1 reflects my proposal in this issue. If we don't land on approach 1 I would still like to get on the same page as to our preferred approach so that we can make the various form inputs consistent.
• Approach 3 matches the current implementation in the DS for text inputs.
• Approach 4 reflects the current DS implementation for checkboxes. .

[dan-padgett]

Overall, I think approach 1 is the best of these options since it doesn't "yell" at the user while they are trying to fix the issue. In other words, having a hover and focus state that maintains the red outline suggests that the user is (still) doing something wrong when they may be trying to fix the problem. If the validations are performed as soon as the user clicks out of the field, then, if there's still an error, change the outline back to red. But if the validations won't be performed until the user clicks "submit", changing the outline back to red before they click "submit" again makes it seem like they've done something wrong before their changes have been checked.

[natalia-fitzgerald]

@dan-padgett Thanks for your feedback. Another nice thing about Approach 1 is that it could be consistent across all inputs, even buttons and links if we decided to implement this across the full universe. Then when a user sees a blue solid outline they know that's hover (regardless of state). This would also be simpler to maintain from a code and Figma library perspective.