Error message

[govuk-design-system]

Use this issue to discuss this component in the GOV.UK Design System.

[36degrees]

Now that the error messages we present use a simpler more instructional language, I think we are relying slightly more on the visual presentation of the error message to help the user understand that they have 'done something wrong'.

Thinking specifically about the way that a screen-reader user would encounter an error message:

National Insurance number, text field. It’s on your National Insurance card, benefit letter, payslip or P60. For example, ‘QQ 12 34 56 C’. Enter a National Insurance number in the right format. You are currently inside a text field. To enter text in this field, type.

I don't think it's entirely clear that "Enter a National Insurance number in the right format" is being included here as an error - because the red and bold visual presentation is missing. We (hopefully) have the error summary at the top of the page, but I wonder if it is also worth adding a visually hidden "Error:" prefix to the error message:

National Insurance number, text field. It’s on your National Insurance card, benefit letter, payslip or P60. For example, ‘QQ 12 34 56 C’. Error: Enter a National Insurance number in the right format. You are currently inside a text field. To enter text in this field, type.

Thoughts?

[stevenaproctor]

@36degrees I think this is a good idea because there is no guarantee that people will hear the message twice or remember it from the first time if they do.

I will have a chat with our accessibility champion and get their opinion too.

[stevenaproctor]

@36degrees Our accessibility champion thinks it would be beneficial, especially for fields with hint text where what is read out is more verbose.

A quick question, the guidance says "if the error relates to specific text fields within the question, give these a red border as well". Should this apply to date fields too? In the example, these do not have red borders but they are text fields. What do you think?

[maya]

I noticed on the error states, the labels aren't bold anymore. What led you to do this?

Before: https://govuk-elements.herokuapp.com/errors/

After: https://design-system.service.gov.uk/components/error-message/

[dashouse]

@maya

UPDATED TO CLARIFY

Our default label is regular weight because the same label component is shared by text inputs, radio and checkbox items.

One thing we noticed (when building the new Design System) when looking at existing services was that many of our users were bolding their label, this was mainly because they were mixing content on the same page. For example this Passport details example below has a label + a text input and a fieldset grouping 3 inputs with separate labels.

In this scenario the questions themselves need the same hierarchy, so the label and legend are bolder and larger than the labels contained within the fieldset

We've made it easier to style labels and legends in a way that works for the questions you're asking.

For example:

Because we also have the "One thing per page" approach often our legends or labels are actually the page heading, which is large and bold.

You can read about our options for labels, legends and headings here - https://design-system.service.gov.uk/get-started/labels-legends-headings/

Another factor that because this original guidance was a little buried it was rarely implimented, here's an example of an error from a service:

Because of all of the above, when we looked at the error states we didn't move the bold label style across to the new system because in many cases the label would already be bold and we considered the combination of the bold error message itself, border style and the error summary (https://design-system.service.gov.uk/components/error-summary/) to be enough.

[timpaul]

Working group review session

A proposal to add error message templates was reviewed by a panel of designers from GDS, HMRC, DWP, DEFRA and Home Office on the 16 August 2018.

The panel agreed that the pattern should be published in the GOV.UK Design System and also made the following recommendations.

• add information to the research section about where the pattern has been used successfully
• make sure the the error message examples are reflected in the coded examples
• provide example errors for file upload and select components
• provide example questions for the radio and checkboxes components
• find out if users have been confused by the ‘enter a real date of birth’ message
• make the link from the error messages documentation more prominent
• remind users that they should always test their error messages

[StephenGill]

Suggested addition - only display one error message at time.

Write your validation script so it displays error messages in a logical order, eg

if (field is blank) {then display "you must answer this question" error message}
else if (value doesn't meet validation rules) {then display "must meet these criteria" error message}
etc

If you need to tell the user about more than one error in a single field, show a single error message telling the user to do the thing that's most likely to fix the error.

Relates to a discussion on the x-gov content Slack.

[gazjoy]

I have an example of a field with multiple errors. This one is an edge case though as there will be a maxlength on the input but that can be removed.

[stevenaproctor]

@gazjoy maxlengths can cause problems for people when they are pasting something in a text input or textarea. It is better to make the input as flexible as possible and allow longer entries and then provide an error.

I agree with @StephenGill's approach to only show one at a time. Validate the field in a priority order then show the error that is triggered first.

[jfhector]

Hello all, could someone explain to me why it's not recommended to display an error message as soon as a user moves away from a field? Thanks a lot

"Only display an error when someone tries to move to the next part of the service. Do not show error when they move away from a field"