No semantics to distinguish labels, hint texts and error messages

[selfthinker]

When we have a hint text and/or an error message under a label, we currently put everything into the label element and only separate them with spans. That is not very semantic and means it gets read out all at once by screen readers.

Example

Example "full name" within Elements

Screenshot

Code

<label for="example-full-name" id="error-full-name">
    <span class="form-label-bold">Full name</span>
    <span class="form-hint">As shown on your birth certificate or passport</span>
    <span class="error-message">Error message about full name goes here</span>
</label>

Screen reader output

"full name as shown on your birth certificate or passport error message about full name goes here"

Screenshot without CSS

Is this actually a problem?

This is probably just a relatively mild issue for screen reader users as they will be used to missing or small pauses between various texts. But it would be good to get confirmation from real screen reader users how big or small this issue is. @edwardhorsford told me there was a discussion about this before. Can you add a reference to that here?

But another issue is that this generally doesn't make a lot of semantic sense. You can best see the lack of semantics when you disable the CSS (see screenshot above).

Potential solutions

Add punctuation

Adding punctuation could work in general but will be really difficult to apply as form labels, hints and error message can be so very different per form. They are sometimes several sentences, sometimes a single sentence, sometimes just a word or several words with or without already existing punctuation.
So, this could only work with a complicated set of guidance, which, in my opinion, rules this solution out.

Move out of label into paragraphs

Ideally labels, hints and error messages should be in their own paragraphs. But that is not possible if they're in the label as it would be invalid HTML. There are some people who also argue that if everything is within the label, it is too verbose for screen reader users.
So, another solution would be to move them out of the label and make the relation between them with aria-describedby instead. For example:

<label for="example-full-name" id="error-full-name" class="form-label-bold" aria-describedby="error-full-name-hint error-full-name-error">
    Full name
</label>
<p class="form-hint" id="error-full-name-hint">As shown on your birth certificate or passport</p>
<p class="error-message" id="error-full-name-error">Error message about full name goes here</p>

Other solutions

I'm pretty sure there must be a couple of more solutions. But that is probably for a team which includes designers and content designers to figure out.

[cjforms]

Is there a possible benefit for maintenance of forms in future?

With semantic markup, it ought to be much easier to extract the different text elements according to their use, and therefore to compare / check / decide whether they need to be updated.

For example, I can see a circumstance in which all the 'first name' boxes across GOV.UK need to be updated with a different hint text, such as 'as shown on your passport or driving license'. A much easier job if you have markup saying that there's hint text.

[timpaul]

Assuming 'ariadescribedby' has good support there are definite advantages to splitting out the hint text from the label. Better semantic structure, more control over positioning etc.

If we did this, we could roll it out in Elements, or save it for GOV.UK Frontend. Thoughts?

[edwardhorsford]

@selfthinker I've forwarded you the thread from last year that I think I was talking about.

A possible downside of going with ariadescribedby is the increased code complexity and opportunity for errors. On the other hand, it would probably give us more control.

[paulwaitehomeoffice]

We had a legend that contained both a label (“Does the person need any support getting around the airport or to and from the plane?”) and hint text (“For example, they are physically impaired or have communication difficulties”).

We tested with a screen reader user (not an actual user of our app; it’s an internal tool, and none of the current users use a screen reader), who found it repetitive to have so much text read out every time a radio button in the fieldset was focused.

Based on this feedback, we removed hint text from fieldset legends. We’ve yet to re-test to see if this causes any other problems.

[36degrees]

This change is being implemented in GOV.UK Frontend.

[36degrees]

Following the launch of the GOV.UK Design System, GOV.UK Elements will now only get major bug fixes and security patches, so I'm going to close this.