design(TextInput): final design review for TextInput component

[shindigira]

closes #239

The TextInput component was already dev verified #239.

Final Design Review of TextInput Component

Verify TextInput component to be used in the component library
Link: https://deploy-preview-279--cfpb-design-system-react.netlify.app/?path=/docs/components-verified-text-inputs--overview

Context

See https://cfpb.github.io/design-system/components/text-inputs

Verification checklist

For existing components

Verify the CFPB Design System (React) component against the CFPB Design System

• Has component intro text copied from the DS page
• Has source link to component's DS page (ex - Source: https://cfpb.github.io/design-system/components/banner-notification)
• Each DS variant is implemented as a separate story
  • Story name should be sentence case (ex. List Link => List link)
  • Naming is consistent with the DS
  • Same component names, same placeholder text, etc.
• Order of stories matches between DS/DSR
• Component is built correctly
  • Visually compare DSR implementation to DS
  • Verify that DS classes (organisms, molecules, atoms) are used, as opposed to styles defined in DSR
• Manual visual review has been conducted and component has passed this review

#### For new components
- [ ] All steps for existing components plus the following steps
- [ ] The new component has been added to the CFPB Design System OR
- [ ] The CFPB Design System maintainers have been alerted that there is a new component that must be added to the system
- [ ] Documentation has been written for the new component (this is not a blocker for moving a component to verified)

Run accessibility checks

• Component is keyboard-friendly (navigable with tab, space, enter, arrow keys, etc.)
• Component does not introduce new errors or warnings in WAVE
• Component is screen reader friendly (screen reader testing demo)
  • Is all the meaningful visual information and text of the component conveyed by the screen reader? (text, non-decorative image descriptions, etc.)
  • When interacting with the component using a screen reader, do you have all the information you need to use it? (selected vs unselected, button vs link, expanded vs collapsed, etc.)
  • Does the component have similar screen reader behavior as the sample components in WCAG, the CFPB design system, WebAIM, or similar accessibility examples?
• For reference: CFPB manual web accessibility audit

Verify component unit tests

• Verify component unit tests are implemented and passing - 85% or greater (ex: yarn vitest Button)

Conduct PR review

• The component has been reviewed and approved by UI, UX, and FEWD

Verify component

• Move component to verified in Storybook

[netlify]

✅ Deploy Preview for cfpb-design-system-react ready!

Name	Link
🔨 Latest commit	d4372b2
🔍 Latest deploy log	https://app.netlify.com/sites/cfpb-design-system-react/deploys/65b181673b9e180008cc3734
😎 Deploy Preview	https://deploy-preview-279--cfpb-design-system-react.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[billhimmelsbach]

Heyo! Did Natalia already look at this to get it verified?

[billhimmelsbach]

Heyo! I don't think @natalia-fitzgerald has seen this for design review. If you think it is ready for design review, could you follow the verification steps over here?

[shindigira]

Heyo! I don't think @natalia-fitzgerald has seen this for design review. If you think it is ready for design review, could you follow the verification steps over here?

I put the verifications in the issue: #239

But I can copy over to this PR as well as name it properly.

[natalia-fitzgerald]

@shindigira
How would you like me to approach the verification of this component? We have pending DS changes to the hover colors for the different status states. Should we complete those changes before or after verifying?

In the DSR we show the different states for the standard text input as individual stories. For the status (Success, Warning, Error) we don't include stories for the states (Default, Hover, Focus). Should we include stories for these states?

In the DS I started some updates to add live code examples of the states for success, error, and warning. As a non-dev in the cuerent Text input DS page it isn't easy to see the styling for the different states. Here's a draft of that approach (note that hover state for success, error, warning is still pending the color update): https://deploy-preview-1880--cfpb-design-system.netlify.app/design-system/components/text-inputs

[shindigira]

@shindigira How would you like me to approach the verification of this component? We have pending DS changes to the hover colors for the different status states. Should we complete those changes before or after verifying?

In the DSR we show the different states for the standard text input as individual stories. For the status (Success, Warning, Error) we don't include stories for the states (Default, Hover, Focus). Should we include stories for these states?

I think we should postpone this then. Will bring the additional TextInput changes into DS, and then into DSR.

Afterwards we can just review it all in one go instead of approving now and then approving again after the changes.

[natalia-fitzgerald]

@shindigira

As we discussed I'd like to group this component as follows:

Sidebar menu text:
Text inputs

• Overview
• Enabled
• Hover
• Focus
• Disabled
• Success
• Warning
• Error
• Full width
• With button
• Button inside
• Button inside (with button)

For Text area input, we discussed making it a separate component in the DSR. Can we do that as a part of this? Does the DS include state styling for Text area input? It's not visualized on the DS page but if it's in the code I'd like to pull it out/itemize it in the DSR.

[shindigira]

@shindigira

As we discussed I'd like to group this component as follows:

Sidebar menu text: Text inputs

• Overview
• Enabled
• Hover
• Focus
• Disabled
• Success
• Warning
• Error
• Full width
• With button
• Button inside
• Button inside (with button)

For Text area input, we discussed making it a separate component in the DSR. Can we do that as a part of this? Does the DS include state styling for Text area input? It's not visualized on the DS page but if it's in the code I'd like to pull it out/itemize it in the DSR.

Thank you for that.

As discussed, we should (in a later issue and PR) make the Text area input it's own component. For this verification PR, I the only remaining task is to rename Default to Enabled.

[shindigira]

@natalia-fitzgerald Updated with the new sidemenu titles. Checkout the preview link.

[natalia-fitzgerald]

@shindigira
This looks good.

@billhimmelsbach or @meissadia what are your thoughts on making Text area a separate component in the DSR? Text input and Text area input both live under "Text inputs" (same page) in the DS. If we decide to do that we can go ahead and open a ticket since this will be needed for the forms work we will likely be doing.

[natalia-fitzgerald]

@shindigira
This looks good. Nice work!

[shindigira]

@shindigira This looks good. Nice work!

Will merge in after approval.

Addressed by @natalia-fitzgerald