Improve Hint text guidance

[joelanman]

We've had some support queries recently relating to Hint guidance.

Currently there's no search result, and it is only covered on the Text input component, when the guidance is relevant to any input type.

[stevenaproctor]

@joelanman There is information in the GOV.UK Service Manual too. https://www.gov.uk/service-manual/design/designing-good-questions#add-help-text-where-necessary

[kellylee-gds]

@joelanman does this need to be triaged? If so please add a "new" label and "submitted-by-user" label

[edwardhorsford]

Some things that came up recently:

• Adding hint text to fieldset component - I asked this. We're using fieldset macro but I couldn't work out how to add hint text.
• Whether hint text should include a full stop some of the time, all of the time, or none of the time.

[36degrees]

• Adding hint text to fieldset component - I asked this. We're using fieldset macro but I couldn't work out how to add hint text.

@edwardhorsford we could provide additional guidance for this, but it's relatively complex so this feels more of a feature request for GOV.UK Frontend to make it easier to do. I've raised an issue over there on your behalf.

[adamsilver]

Currently, the hint text component accepts HTML which is great because it makes the component flexible.

It gets rendered as a <span> with the specified HTML inside of it.

If the HTML consists of block level elements then it becomes invalid.

The following points are relevant:

(1) Interfaces that have a lot of content can be a sign that the design is complicated and needs further work.

(2) If we have done the hard work to keep hint text to a minimum, then we might need to look at other ways to present the information.

Option A: Use an interruption page with the content that needs reading. Once read the next page can contain a simple label/legend + input(s).

Option B: Just have a lot of hint text. This way it’s seen in context of the input and provides a comparable experience for screen reader users.

Option C: Allow hint text to contain the Details component which will let users expand content if they need it.

There may be other options but as a start I’d suggest:

1. Adding guidance to clarify our position on this
2. Make the <span> a <div> to make sure it’s valid when doing Option B or Option C.

[NickColley]

In terms of HTML validation we could consider making the hint component render with a div when supplied with HTML (or at all times) since we make it a block level element anyway with CSS.

[edwardhorsford]

I don't think I quite realised that you couldn't put block level elements in there. I've not checked my whole app, but it wouldn't surprise me if we'd supplied the hint with two paragraphs.

Changing to support this, or providing guidance for what to do in situations where you have more content would be great.

[edwardhorsford]

Would it be possible to mention details about hint text in the typography section? This seems a logical place people might go to look up details / guidance for hint text.

[frankieroberto]

I've definitely used the Details component within hint text. I used it to give further examples – so the Details summary was "Examples" and contained good and sometimes bad examples of how to fill in the field. This was for an internal tool.

[matteason]

We ran into an issue with the hint text guidance the other day - a colleague asked me if it was ok to use links in hint text, because there was nothing on the textarea guidance to advise against it. I found the appropriate guidance on the text input page but it would have been easy to miss.

I wonder if there's an argument for hint text to be considered a component in its own right. That's what's done for error messages and character counts, for example - like hint text, both of those only exist as parts of other components. Individual components that allow hint text could then link to the hint text component guidance, as they do for error messages (for example on the Radios page)