Introduce "add another" component

[dnkrj]

What

• Add the component wrapper helper to fieldsets
• Introduce the add another component based on the MoJ design system and existing component in Whitehall.
• An empty field and destroy checkboxes for the existing fields are required and displayed to the user when javascript is disabled in keeping with rails conventions.
• When Javascript is enabled, an "add another" button is introduced to allow users to add copies of the empty field and the checkboxes replaced with "Delete" buttons which hide the fields and checks the appropriate checkbox.

Why

• This component is to be used when users need to add similar information a couple of times, such as several featured links for an organisation.
• The current implementation in Whitehall requires JavaScript to work correctly
• We want to use the pattern in Specialist Publisher and Mainstream.
• https://trello.com/c/BIfsF9pP/3139-move-add-another-pattern-to-govukpublishingcomponents

Screenshots

To see further examples of usage, the migration PR for Whitehall can be looked at.

The screenshots are taken with input and checkbox styles added to the page.
This are not present in the code in the PR.

With Javascript

Without Javascript

[jon-kirwan]

It's looking good 👍 I've just added a couple of smallish comments.

Also, I think the add-another styles need to be added to the _all_components.scss stylesheet.

[jon-kirwan]

Are there any accessibility issues with having multiple labels and delete buttons that all share the same name? For example, if a screen reader user navigates the form by buttons using the rotor, could this cause confusion? Would it be worth considering adding a visually hidden element next to each label and delete button to make them uniquely identifiable e.g.

<label>Full name <span class="visually-hidden">1</span></label>

and

<button>Delete <span class="visually-hidden">full name 1</span></button>

[dnkrj]

Thanks for the review @jon-kirwan!
You're right that the repeated button labels aren't good for accessibility.
It's a little bit difficult to update them programatically since we don't know exactly what the caller will put in so I've updated the code to wrap all of the fields in a numbered fieldset (and updated the screenshots to match).
This follows one of examples for "Providing Accessible Names and Descriptions" in the ARIA Authoring Practices Guide (APG). Let me know what you think!

[jon-kirwan]

Thanks for the review @jon-kirwan! You're right that the repeated button labels aren't good for accessibility. It's a little bit difficult to update them programatically since we don't know exactly what the caller will put in so I've updated the code to wrap all of the fields in a numbered fieldset (and updated the screenshots to match). This follows one of examples for "Providing Accessible Names and Descriptions" in the ARIA Authoring Practices Guide (APG). Let me know what you think!

Thanks, that looks better! There's still an issue with identifying the form components with the rotor. However, when using VoiceOver to navigate the page, the unique fieldset is announced each time you tab to an input, which will be helpful

[jon-kirwan]

Great work and thanks for answering all my questions @dnkrj!

[davidtrussler]

Hello @dnkrj Just been looking at this - looks really good. The only thing that came to mind was to maybe explain a bit more in the documentation about the empty item: I don't think it's immediately obvious what that does and how it should look.