[Eng] Update UI for Personal Information components

[nichole-aquino]

Overview

Form builders can easily add/edit Personal Information components (date of birth, Social Security number, email, phone number, gender identity, address)

Context

Reference:

• Design ticket: [Design] Update UI for Personal Information components #429
• Figma mockups
• USWDS components: Date of birth, Social Security number, email, phone number, gender identity, address, unstyled button, delete icon

Rename components:

• Social security number: Change to Social Security number (capitalize Social Security since its a proper noun)
• Email input: Change to Email
• Date of birth phone, gender identity, address: No change

On the build screen:

• Relabel the question input field to ‘Question text’
• Widen the question input field
• For all components, the fields are pre-filled for builders (for example, "Date of birth"). They could leave them as is, or edit to match the rest of their form (for example, "What is your date of birth?)
• For all components, remove the ability to edit the hint labels since these are standard (e.g. For example, 555-11-0000 for SSN)
• For gender identity, remove the ability to edit the “prefer not to answer” checkbox.

All forms should include this according to USWDS guidance, so builders should not have the ability to edit/remove it. So builders have some awareness of this checkbox, the component will be described as: An input to collect gender identity with an option to select "prefer not to answer.”

• Add optional help text component with grey text style; the field grows as needed (GH ticket #373)
• Add optional information box component 'Add supplementary information or instructions' (GH ticket #415)

Acceptance Criteria

The changes should be made to the following question types:

• Date of birth
  
• Social Security number (formerly spelled Social security number)
  
• Email (formerly called Email Input)
  
• Phone number
  
• Gender identity
  
• Address

Research Questions

• Optional: Any initial questions for research

Tasks

Research, design, and engineering work needed to complete the story.

• [ ]

Definition of done

The "definition of done" ensures our quality standards are met with each bit of user-facing behavior we add. Everything that can be done incrementally should be done incrementally, while the context and details are fresh. If it’s inefficient or “hard” to do so, the team should figure out why and add OPEX/DEVEX backlog items to make it easier and more efficient.

• Behavior
  • Acceptance criteria met
  • Implementation matches design decisions
• Documentation
  • ADRs (/documents/adr folder)
  • Relevant README.md(s)
• Code quality
  • Code refactored for clarity and no design/technical debt
  • Adhere to separation of concerns; code is not tightly coupled, especially to 3rd party dependencies; dependency rule followed
  • Code is reviewed by team member
  • Code quality checks passed
• Security and privacy
  • Automated security and privacy gates passed
• Testing tasks completed
  • Automated tests pass
  • Unit test coverage of our code >= 90%
• Build and deploy
  • Build process updated
  • API(s) are versioned
  • Feature toggles created and/or deleted. Document the feature toggle
  • Source code is merged to the main branch

Decisions

• Optional: Any decisions we've made while working on this story