How to design accessible hint text

By Angela Moore and Ben Millar

Angela’s a content designer and Ben’s a developer. They have worked together for a few years and spend a lot of time and energy making sure all the bits of services are accessible.

Hint text confessions

I admit to having an unhealthy little obsession with hint text. Over the years, I have been at the forefront of much hint text hooha. My obsession has ranged from the prosaic (should hint text take a full stop) to the existential (do people notice hint text anyway (opens in new tab).)

GDS recently called it on the full stops - the design system says no. I disagree, on balance, because I think it’s potentially not great for screenreaders; but I am also delighted to finally have an end to the endless questions about this.

However, I still think we’re often misusing hint text in services, and I still worry about it. Here’s why.

What is hint text?

Hint text offers brief, additional information about how to fill out a form field. When we use it well, it gives users just a little bit more information to help them answer a question.

In the GDS design system, hint text is not treated as a separate component, but added into component guidance for other form components, such as checkboxes (opens in new tab).

The DWP design system does treat hint text as a separate component, and offers some excellent advice. Disclaimer - I contributed to this! Read guidance in the DWP design system hint text (opens in new tab).

What is good hint text?

The best hint text is:

evidence-based
short - no more than a few words
words only - no links, bullets or other fancy bits

The best hint text comes from research showing that lots of users need the information you’re providing. If you don’t need hint text, do not add it in - you’ll be adding cognitive load for no reason.

And the best hint text is short. Ideally, just a few words. As the DWP design system says, if you find yourself needing to write more, it’s probably because the question is confusing and needs to be clarified, improved, or split into more than one question.

You should also never use bullets or links inside hint text. This is because of the way hint text is handled in the code.

This is an example of bad hint text. Do not do this. It is not accessible.

This image shows a question, hint text and a freetext field. It uses the question design from the GDS Design System. The hint text is very long, 32 words. It uses bullet points.

How hint text works in the GDS design system code

(This is where I turn to my colleague, Ben, to help me understand what’s happening in the code-y bits of hint text. Thanks, Ben!)

To link hint text to form fields, the GDS design system specifies that, in HTML, we use the aria-describedby attribute.

This attribute lets screen readers associate the hint text content with an input field (or fieldset, for grouped questions), ensuring that users hear both the field label and the additional instructions when they focus on the input (or fieldset).

For example:

html
CopyEdit
<label for="email">Email address</label>
<input type="email" id="email" aria-describedby="email-hint">
<p id="email-hint">We'll only use your email to send service updates.</p>

When a screen reader user focuses on the input field, they hear both the label "Email address" and the hint "We'll only use your email to send service updates."

This approach works well for short, focused hints. However, using aria-describedby for long paragraphs or complex content with semantic or interactive elements can cause serious problems.

Do not include links, bullets or anything other than words

Screenreaders will probably not:

recognise and announce links or other interactive elements
recognise bullet points, paragraphs or other semantic elements

Hint text should be text only.

Do not write long hint text

Even if we mean it to be useful, associating lengthy or complex content with input fields can create problems for screen reader users.

Using the aria-describedby attribute for hint text means that screen readers will likely just read the whole bit of content as a long, run-on sentence.

Also, screen readers will always read out all the content in a hint text. Long paragraphs can frustrate users who simply want to fill in the field quickly, or who might have lost track of the question by the time they get to the end of the hint text.

This is confusing and annoying.

So, what should we do instead?

We sometimes need to provide a lot of guidance or information for people who are answering a question. We know we can’t use hint text to do this. So what do we do?

Well, luckily the fabulous people at the GDS design system have solved this problem for us. There’s an established way of separating your supplemental information from the the label of a form field - read about asking complex questions without using hint text (opens in new tab).

It looks like this:

The image shows a component from the GDS design system. It has an H1 header. It's followed by a few paragraphs of text. The text includes a link. Then there is a question label, two yes/no radio buttons and a green button to continue.

There is also a component in the design system which will work for you if you want to provide information only for people who need it, without cluttering up the content for everyone else.

That’s the ‘Details’ component, and it looks like this:

The details component is a short link that shows more detailed help text when a user clicks on it. The image shows a short link called 'Help with nationality', which has been opened to reveal a short paragraph of text.

Yes, but [insert special pleading for your service]

I know. It is sometimes really hard to make everything work right in a service. I think it’s especially hard to handle supplemental information in case management or other internal services, where you might have multiple form inputs on a page. Suddenly the pattern for asking complex questions - that goes header-guidance-label-input - doesn’t look as nice and tidy as it does on the GDS example, where there’s only one question being asked.

But we know we cannot do things that are not accessible. And that’s where we come in as content designers. It’s on us to design our socks off to strip complexity out of questions, and work out the right balance of information for each question.

If it’s not accessible, do not do it.

Be amazing designers of hint text!

So, to round up: we have to structure form guidance properly. It will benefit all users, including people who rely on assistive technologies.

By designing gorgeously simple hint text, basing it on evidence, and putting it in only the right places, we can create user-friendly and accessible forms.

Keep it short. Keep it simple. Put it in the right place. Fabulous!

Talk to us about your own hint text obsession, or about making your content accessible to everyone.