Hint text for form fields/Refactor Input Text component

[pollecuttn]

What Placeholder text disappears when a form field is navigated to. Users need additional cues / hint text whilst filling in a form field.

Where Form fields

TODO

• [ ] Provide additional cues / hint text that persists whilst filling in a form field
• [ ] Add pattern to Cardigan

Background

From the Hassell Inclusion accessibility audit August 2023.

Dovetail: https://proficient-wallaby-dpwd.dovetailapp.com/insights/Need-additional-cues-for-entering-information-in-form-fields-MjtohTWntPJtuP7J1y1YJ

Miro board: https://miro.com/app/board/uXjVMjsL5YE=/

[j-jaworski]

I think we have 2 options here

1. Use the form elements developed and defined for Wellcome FRP (Funding Relationship Platform product) and have been used across many of the other products at Wellcome.

Designs in Figma https://www.figma.com/file/6bg5Y3Y4gLXgSdVa8Da8Vy/Wellcome-design-system?type=design&node-id=1429%3A5466&mode=dev&t=ALVqWmijUaT4oAZA-1

2. Use the UI that is used on this page across the whole site (although I can't point you towards designs for this option) https://account.wellcomecollection.org/u/signup?state=hKFo2SAzRk1fLW1sb2hEZlo3dWRrcU1aR0xDRElXaDBlSl9Hb6Fur3VuaXZlcnNhbC1sb2dpbqN0aWTZIGxXLThmUlFqSXQ5WWZGZzZuOGxOT3dIeklfaU9zc01Zo2NpZNkgT3lGdjJIS0E0a1E2d2lDYjFXMDU5S1NMdVg5Z1V6cWg

[davidpmccormick]

Option ii. is similar to what we'd previously built ourselves, but I think we reverted to a more traditional (closer to option i.) approach for simplicity a while ago. The example in the link above is actually an Auth0 hosted page, so not an input we have control over.

I think given we moved away from option ii. the obvious route for us to take is to fill out what we already have in line with option i. In this case, would you suggest updating everything in line with the FRP form fields, or just adding the hint text to what we have in the first instance?

We recently updated the validation error messaging (#10318) to include an example email format ('name@example.com') as a result of a related thing that came out of the accessibility consultancy research. From memory, GOV.uk was referenced as the gold-standard of how to handle this – I've just had a look at the Email address pattern in the GOV.uk design system and while it does have hint text, that interestingly doesn't reference the email address format (or include any placeholder). What do you think @j-jaworski?

Currently we always have a <label> which is always visually hidden, and an optional placeholder which will display inside the input as the placeholder attribute if it's present, or if not, the label text will appear as the placeholder. If we kept the visually hidden label but added an optional e.g. hint, then maybe we should move anything that currently appears as placeholder text into this above-the-input 'hint' area? This might lead to a bit of duplication for screenreaders. For example, the (visually-hidden) <label> for this input is 'Your email address', so a screenreader would hear something like, 'Your email address, Your email address e.g. name@example.com'. Not sure if this would be a problem in reality.

Maybe we could take a look at the actual text inputs on the site and make a decision based on that – I don't think there are too many of them.

[rcantin-w]

AFAIK it's only the search bar (which is displayed in an array of pages but always with the same component) and the newsletter pages (the block at the bottom of pages and the one on /newsletter.

[j-jaworski]

Lots in this and trying to unpack it all and make sense, apologies if I have misunderstood or missed something.

My thoughts:

• Update form inputs to align with the UI with the FRP (either all together in one ticket or just the hint text field for now, however, you want to split the work)
• Keep the current validation error messaging for emails
• Add hint text message that guides the user
• Where possible remove duplication in the UX copy, specifically between the label and hint text

I have added designs for this pattern to this Figma file https://www.figma.com/file/juZQR2wi2BsYG8TDH6R4uk/Wellcome-Collection-%E2%80%93-Styles-and-Component-Library-2023?type=design&node-id=1776%3A4028&mode=dev&t=Cu6Gm9mlde1dQRlV-1

Here are some screenshots for reference

[rcantin-w]

Ahh I'm sorry, I was very wrong about saying there were only three inputs. I was only thinking about forms and within the main website. I'm not so familiar with Identity yet, so I didn't realise.

I'm throwing a few more in the mix.

Item viewer search:

This one needed a change as you can't even read the whole placeholder, so good to align.

Identity info changes:

There's another modal where you can change your email address that uses the same inputs. These are interesting because they're different from the two styles in the original ticket description, kind of an in-between. I think it might be a leftover from the fact that (I think?) an agency built Identity (I think?). Anyway, they can be aligned too, the ones we can't touch in Identity are the ones related to logging in and signing up.

Pagination:

This one is pretty self explanatory and is never empty, so maybe no visible input needed.

Dates filter:

I'm unsure about what should be done here. Similarly to Pagination. They do use a "NumberInput" component versus the others which are "TextInput", so it could behave differently.

[rcantin-w]

Changes are in prod