VATEAM-101160: Create "Custom Step" paragraph and text input component in Drupal

[derekhouck]

Description

Creates several new Paragraph and field types:

• Custom Step is a new step that allows form builders to create steps following the Single Response pattern. It includes a step header and pages.
• Page is a new paragraph type representing a form page from the above pattern. It includes a page title, body text, and one or more components.
• Text Input Component is the first of several components that can be embedded within Custom Step Pages. It contains fields common to all Custom Step Components: "Label," "Hint text", and "Required?"

These will all be used within the Digital Form content type.

• Closes Create "Custom Step" paragraph and text input component in Drupal va.gov-team#101160

Testing done

Manually created a Digital Form with a Custom Step that featured multiple pages and components within it.

Screenshots

The turducken of a Digital Form containing a Custom Step containing a Page containing a Text Input Component

QA steps

As an administrator

1. Go to Manage > Content > Add content > Digital Form
2. In the "Steps" field, click "Add Step"
   • Verify "Digital Form: Custom Step" appears as the top pattern in the "Add Step" modal.
3. Click "Add" underneath "Digital Form: Custom Step"
   • Verify the "Digital Form: Custom Step" Paragraph appears expanded in the "Steps" field.
   • Verify the "Step header" field is required
   • Verify the "Pages" field is present and populated with a Digital Form: Page Paragraph
   • Verify the Digital Form: Page Paragraph is expanded in the "Pages" field.
   • Verify the "Page title" field is required
   • Verify the "Body text" field is optional
   • Verify the "Components" field is present and populated with a Digital Form: Text Input Component Paragraph
   • Verify the Digital Form: Text Input Component Paragraph is expanded in the "Components" field.
   • Verify the "Label" field is required.
   • Verify the "Required?" checkbox is unchecked.
   • Verify the "Hint text" field is optional.
4. Fill out the required fields on the Digital Form and click "Save" at the bottom of the page.
   • Verify the Digital Form saves successfully.
   • Verify the "Digital Form: Custom Step" Paragraph is included in the "Steps" field of the view page.
   • Verify all the data you entered is reflected on the view page.

Definition of Done

• Documentation has been updated, if applicable.
• Tests have been added if necessary.
• Automated tests have passed.
• Code Quality Tests have passed.
• Acceptance Criteria in related issue are met.
• Manual Code Review Approved.
• If there are field changes, front end output has been thoroughly checked.

Select Team for PR review

• CMS Team
• Public websites
• Facilities
• User support
• Accelerated Publishing

Is this PR blocked by another PR?

• DO NOT MERGE

Does this PR need review from a Product Owner

• Needs PO review

CMS user-facing announcement

Is an announcement needed to let editors know of this change?

• Yes, and it's written in issue ____ and queued for publication.
  • Merge and ping the UX writer so they are ready to publish after deployment
• Yes, but it hasn't yet been written
  • Don't merge yet -- ping the UX writer to write and queue content
• No announcement is needed for this code change.
  • Merge & carry on unburdened by announcements

[github-actions]

GitHub Workflows (.github/workflows/*.yml)

Have you...

• pinned all affected GitHub Actions at a specific commit by SHA?
• reviewed the source code of the action at the commit you are pinning?
• confirmed that no GitHub security measures are being bypassed?
• checked for any injection of user content into protected contexts?
• reviewed Security hardening for GitHub Actions?
• reviewed GitHub Workflows?

[github-actions]

Checking composer.lock changes...

[laflannery]

• All Text input fields:
  • There are character limits on these fields but I am not told I've hit it, my typing just stops. The user needs feedback as to what is happening.
  • Please follow the format/UX of the Page title field on the Benefits Detail page (I know many other fields also have this same character counter I just picked this as the example)
  • Screen shots:
    
    
• Body text field:
  • Please make the "t" in the label Body text lower case to match VA style guide (they use sentence case and we do our best within the CMS to adhere to that as well)
  • Within the help text, it is suggested that if necessary, the user could use an additional info component, however they aren't given the option to add this component anywhere.
    • (Apologies if this is out of scope for this particular PR but I wanted to make sure it was noted just in case)
  • I might suggest adding a character count to this field as well especially since there is a word count suggested in the help text
• Label field:
  • I think it could be beneficial to add help text to the label field. However, without more context as to what exactly this is and who the user base is I can't say for sure.
  • Overall we have been adding more help text to fields lately so I would definitely encourage it or at least reviewing this with your own UX folks and thinking about this more long term - if this were to be opened up to more users, would having help text be beneficial?
• Paragraph images:
  • We don't typically use these little paragraph images within the CMS, are these able to be removed?
  • If not, could the title attribute be removed from both of them? There are very few instances in which the title attributes should be used and in this case it is not necessary and just adds noise.
    

Please let me know if there are any questions on any of the above feedback

[github-actions]

Checking composer.lock changes...

[github-actions]

Checking composer.lock changes...

[github-actions]

Checking composer.lock changes...

[github-actions]

Checking composer.lock changes...

[derekhouck]

@laflannery, I believe I have addressed all your feedback and the PR is ready for review.

[laflannery]

Looks good!

[ryguyk]

Very nice work!

I left one question about a very small text consideration.

More notably, the work here to add character counters, for example, brings to the forefront the distinction between the default node-edit form and our Form Builder UI's forms. Currently, these configurations (like character counters) do not come over to the Form Builder UI. For one, they are not called for in the designs. For two, getting them to come over is not automatic. We can pull the widgets into our Form Builder UI, but we need to decide if that's something we want to do.

[ryguyk]

Should this say "50" rather than "fifty"?

[derekhouck]

I copied it from VADS and went with whatever they used.

[laflannery]

@ryguyk Regarding your character counter comments, my comments were more from an accessibility and usability standpoint rather than a "let's match the Drupal UI" standpoint. If something is not happening (e.g. the text I'm trying to type is not actually typing), the user should know why. So I'm up for doing it a different way in your From build UI if that's better for you all but there should be some feedback for the user in these types of instances.

Let me know if you think we should discuss further. And in general when I provide feedback I'm probably always going to default to the Drupal UI I know but if you ever need to push back always feel free and we can discuss the why and see if there's a better solution for what you all are building

[github-actions]

Checking composer.lock changes...

[github-actions]

Checking composer.lock changes...

[github-actions]

Checking composer.lock changes...

[github-actions]

Checking composer.lock changes...

[va-cms-bot]

Cypress Accessibility Violations

/test-data-soluta

ID: button-name
Impact: critical
Tags: cat.name-role-value, wcag2a, wcag412, section508, section508.22.a, TTv5, TT6.a, EN-301-549, EN-9.4.1.2, ACT
Description: Ensure buttons have discernible text
Help: Buttons must have discernible text
Nodes:

• HTML: <button class="proofing-element-help" role="tooltip" data-proofing-help-title="About 'Page introduction' field" data-proofing-help="Add an introduction that helps visitors understand if information on the page is relevant to them."> <span aria-hidden="true">i</span> </button>
  Impact: critical
  Target: .field--name-field-intro-text-limited-html > .field__label > .proofing-element-help[role="tooltip"]
  Summary: Fix any of the following:
  Element does not have inner text that is visible to screen readers
  aria-label attribute does not exist or is empty
  aria-labelledby attribute does not exist, references elements that do not exist or references elements that are empty
  Element has no title attribute
  Element does not have an implicit (wrapped) <label>
  Element does not have an explicit <label>
  Element's default semantics were not overridden with role="none" or role="presentation"

• HTML: <button class="proofing-element-help" role="tooltip" data-proofing-help-title="About 'Generate a table of contents from major headings' field" data-proofing-help="By checking this box, all h2's below this point on the page will be linked with with anchor links. This helps users navigate content on very long pages. Do not check this box unless there is at least 2 h2's on the page.">
  Impact: critical
  Target: .field--name-field-table-of-contents-boolean > .field__label > .proofing-element-help[role="tooltip"]
  Summary: Fix any of the following:
  Element does not have inner text that is visible to screen readers
  aria-label attribute does not exist or is empty
  aria-labelledby attribute does not exist, references elements that do not exist or references elements that are empty
  Element has no title attribute
  Element does not have an implicit (wrapped) <label>
  Element does not have an explicit <label>
  Element's default semantics were not overridden with role="none" or role="presentation"

• HTML: <button class="proofing-element-help" role="tooltip" data-proofing-help-title="About 'Main content' field" data-proofing-help="The main body of the page, which appears below the featured content."> <span aria-hidden="true">i</span> </button>
  Impact: critical
  Target: button[data-proofing-help-title="About 'Main content' field"]
  Summary: Fix any of the following:
  Element does not have inner text that is visible to screen readers
  aria-label attribute does not exist or is empty
  aria-labelledby attribute does not exist, references elements that do not exist or references elements that are empty
  Element has no title attribute
  Element does not have an implicit (wrapped) <label>
  Element does not have an explicit <label>
  Element's default semantics were not overridden with role="none" or role="presentation"