Error summary

[govuk-design-system]

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

[stevenaproctor]

It would be good to have a consistent heading in the summary.

"There is a problem" has tested well with users.

The "Optional description of the errors and how to correct them" does not add any value to the screen. It does not provide context or help describe what has gone wrong. The heading does the first and the error does the second.

[ignaciaorellana]

Thanks @stevenaproctor The Working Group will be reviewing this change in the next review session (April) because of lack of time (already have 5 contributions to look at on the 22nd)

[fofr]

We used this component as part of the publishing workflow alpha:

• https://github.com/alphagov/whitehall-prototype
• https://whitehall-prototype.herokuapp.com/patterns/flash-notices

We tested it with 5 users and noted that none of them interacted with the red links in the error summary box. This didn't prevent them from reading the message and they were able to find and fix the errors.

This was also true when the error summary was shown on a document summary view, where the errors were in forms on a different page (where we considered the links to be most useful).

cc @BlancaTortajada

[BlancaTortajada]

We haven't specifically used the "Optional description of the errors and how to correct them" text in our error summary box in the publishing workflow prototype, but whenever there was some guidance text between a heading and an interactive element on another page, the text tended to be overlooked almost every time.

[timpaul]

Thanks both. The intension is that the links are primarily for the benefit of people using screen-readers and keyboards, as it gives them a quick way of jumping to the relevant errors, rather than having to navigate through the whole form.

However, I'm not aware that we've validated whether this approach works for these users or not. If you ever do some research with users of assistive tech then this would be something to look out for.

[stevenaproctor]

@fofr I think you still need to show the errors at the field level using #47. This will make it easier for them to find the errors on the form.

@BlancaTortajada The "Optional description of the errors and how to correct them" never actually adds anything to the screen. I think we are looking at removing it from the pattern.

[BlancaTortajada]

@timpaul Thanks Tim! We'll let you know if we find anything about that in our upcoming missions.

[fofr]

@stevenaproctor Yep, we do both. The screenshot is an example of a summary page without any of the fields. Clicking through to the sub-pages shows the relevant error and highlights the field.

[adamsilver]

Currently:

• the error summary is 100% width. Should we give the component a max width?
• when using the one thing per page pattern whereby the h1 is the label/legend, the error summary's h2 title comes before the h1. We don't want that, nor do we want two h1's. The question is, what do we want? :)

[NickColley]

Should we give the component a max width?

I don't think so, all our components fill their parent containers. This consistency means we make no assumptions on the layouts these components will be used in. For example if someone decided to make their own grid layouts they might be forced to override this max-width.

In the most general case we'd want to use the grid layout classes, which will be consistent across our components (or we've talked about having a 'measure' layout wrapper too)

[adamsilver]

I'd be happy with a measure class (that I could put on a wrapper, or on the error summary container).

On Mon, 2 Jul 2018, 18:09 Nick Colley, notifications@github.com wrote:

Should we give the component a max width?

I don't think so, all our components fill their parent containers. So we can use the grid system here. (or we've talked about having a 'measure' layout wrapper too)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/alphagov/govuk-design-system-backlog/issues/46#issuecomment-401871827, or mute the thread https://github.com/notifications/unsubscribe-auth/AACRK85Irb8b9aUUdoQy8pFX-C9ixm__ks5uClPSgaJpZM4Rcf5N .

[stevenaproctor]

In elements, the error summary was inside a div with a column-two-thirds class. Would it be a good idea to put the examples here inside a div with a govuk-grid-column-two-thirds class?

[adamsilver]

Yep, so I spoke with Nick about this before. The two-thirds grid acts a little differently to a max-width.

The grid 2/3 means it's always two thirds (except for mobile). But that means it's unnecessarily small (unless at full width).

The measure (max width) version, would mean it's 100% until it hits X pixels. This is the behaviour I want on quite a lot of components.

For me, grid, should only be used when you want things to be next to each other.

[stevenaproctor]

Do you have any screenshots for how it would look? For me, the 2/3 grid acts like a measure. When content is outside the measure it can make a screen look disjointed. What do you think?

[adamsilver]

Note: the width of my prototype is wider than normal.

Using grid (full width viewport)

This is basically fine.

Using grid (half width viewport)

Here the error summary is unnecessarily narrow. Using a max-width approach instead, would make the error summary full width under this scenario.

[stevenaproctor]

So the error summary would be as it appears in the first screenshot but the decision notes box would be like the second?

[adamsilver]

Well, that's another thing. I'd say this max-width thing should be put on the <form> (or similar) too.

Basically, for pages that are single column (that's probably the majority) don't need to use a grid—just need the max-width applied for certain elements.

For other things, such as tables with lots of columns, I'd let them go full width (max width 100%)—so wouldn't need a max width there at all.

[stevenaproctor]

I am not a frontend developer so I am not sure the best solution from a CSS point of view. The grid makes sense to me as a container for the content of the page and means I do not need to put a class on every element to control its width. It is a guaranteed way to make sure no line of content is more than 75 characters.

I worked on a service that had full width tables and 2/3 width content. It did not make the screen less usable but it looked disjointed. Because I know this can cause problems for some people I always try to keep content in the 2/3 grid. If a table has lots of columns and does not, it may be better as more than one table especially for people using a mobile.

the error summary is 100% width. Should we give the component a max width?

I do not think it is. Because the examples are snippets, there is no grid. If you look at the examples from elements that show the errors in context, the error summary is in the grid. http://govuk-elements.herokuapp.com/errors/

when using the one thing per page pattern whereby the h1 is the label/legend, the error summary's h2 title comes before the h1. We don't want that, nor do we want two h1's. The question is, what do we want? :)

We used to use 2 h1s but that was changed to a h2 above the h1. You can see the pull request and discussion at https://github.com/alphagov/govuk_elements/pull/510

[adamsilver]

Hey Steven, reading back I don't think I was very clear.

I think the page should conform to a grid, but I don't think a single column page (like the one I showed above) needs to use the grid classes.

If we were to have say a .govuk-measure-x class then perhaps I'd suggest the max width value would match the 66% (2/3 grid) class used for grids.

That said, I suspect it's not that simple, because a 66-33 grid isn't the only combination. We can use 50-50 etc.

Also, I'd say the max width of the error summary should be the same across all screens, even if it sits above some pages with single column, some with 66-33 and others with 50-50.

Is that a bit clearer?

(Thanks for the note about the h1/h2 thing.)

[jonathaninch]

What would be good practice for an error summary involving a radio button?

For example, if we ask the user "Is this the registered name of your business?" (and show a business name pulled from the backend) and they have a Yes / No radio button option I would have an error message something like "Select if this is the registered name of your business" but I'd struggle a bit with the error summary.

"Select an option" - too generic for an error message (but acceptable for a summary?) "Select if this is the registered name of your business" - same as the message (or is this acceptable?) "Indicate if this is your business name" - using fofr's example above?

Radio buttons seem a bit tricky when it's potentially just Yes / No.

[stevenaproctor]

@jonathaninch For your example, I would say 'Select yes if this is the name of your business'. But I would consider adding the name of the business into the H1 and then saying 'Select yes if [name] is the name of your business'.

The guidance in the Design System says "show the same error messages next to the inputs with errors". There is more information about this on the error message guidance. See https://design-system.service.gov.uk/components/error-message/#be-consistent

[jonathaninch]

@stevenaproctor Cheers Steven - that guidance managed to go down the plughole in my brain today, so thanks for pointing it out.

[stevenaproctor]

The error summary border is 4px. The error message left border is 5px. Should these both be 4px or 5px?

[joelanman]

Hi @stevenaproctor just checked the code - I think that would only happen on mobile, which still seems like it might be a bug

[edwardhorsford]

I think it would be helpful to add a bit more guidance on the position of the error summary component. My understanding is that it should come before the page h1, but after things like the beta banner and back link / breadcrumb.

This isn't super obvious at the moment. My team has just implemented this but ended up placing the summary after the h1 - similar to @adamsilver's screenshots above.

The current language 'Use this component at the top of a page to summarise any errors a user has made.' does somewhat cover it, but I feel it could be more specific.

[amyhupe]

Thanks for the feedback @edwardhorsford – we can add it to our team's backlog if you like, or if you have an idea of the wording, feel free to open a PR proposing the specific change?

Let me know which you'd rather.

[edwardhorsford]

Some ideas below - but could do with your love.

I also think it would be helpful for an example to show it in the context of a more complex page - such as one that includes the header and a back link.

I might update this line: show an error summary at the top of a page

Something like: show an error summary at the top of the page - before theh1, but after breadcrumbs or back links.

Could also mention that it's likely to be positioned at the beginning of the main element.

[NickColley]

@edwardhorsford perhaps it can be thought about like 'the first thing within the <main> element', not sure how to communicate that without that technical term.

[NickColley]

A community member on X-GOV Slack:

Can anyone advise on how where in the page an https://design-system.service.gov.uk/components/error-summary/ component should be?

The guidance there says show an error summary at the top of a page. Should I take this to mean:

• below the header
• below the phase banner
• above a breadcrumb
• above a back link
• above the page header

The phase banner component guidance says "Your banner must be directly under the black GOV.UK header and colour bar."

so I'm happy the error summary should be below that.

The back link, however, says "Always place back links at the top of a page." - it's not clear if that means above the <main> content

[jfranciswebdesign]

A community member on X-GOV Slack:

Can anyone advise on how where in the page an https://design-system.service.gov.uk/components/error-summary/ component should be? The guidance there says show an error summary at the top of a page. Should I take this to mean:

• below the header
• below the phase banner
• above a breadcrumb
• above a back link
• above the page header

The phase banner component guidance says "Your banner must be directly under the black GOV.UK header and colour bar." so I'm happy the error summary should be below that. The back link, however, says "Always place back links at the top of a page." - it's not clear if that means above the <main> content

@nickcolley I've always put mine below the 'Back' link, this mirrors what I've seen on live - for example, on "Check if a vehicle is taxed and has an MOT"

[drtux]

Screen Reader (JAWS) read out “There was a problem” in 6 instances in my last round of research.

The participants heard this, and then didn’t pay attention to, or go looking for, the additional information provided in the in-page links about what the problem was.

They felt they were on a new page and that the best course of action was to immediately browser back, with the expectation of getting back to the page where they input the rather than editing/correcting the error on the current page.

Here is an example from our service (with other known issues), this wasn't the only instance of this pattern that saw this user behaviour during this testing round.

[chrisadesign]

What about a combo of what @edwardhorsford and @nickcolley mentioned, eg show an error summary at the top of a page as the first thing within the <main> element – before the h1, but after breadcrumbs or back links

[ChazUK]

After having a conversation with the designer and content editor on the project I'm working on, they are moving away from the recommendation of show the same error messages next to the inputs with errors. I was wondering how important this is and if there's any user research to back it up.

Personally I thought it was a bit weird to begin with, but now feel that it works quite well and to change the error messages between the summary and next to the field in question would confuse the user.

[edwardhorsford]

@ChazUK On passports we varied. Much of the time it was the same message, but sometimes we wanted something a bit more specific in situ. As long as the message is clear, I don't think it's essential to be identical.

[edwardhorsford]

Posting to summary list, but it's more about validation in general.

---

My service has a few pages where the user is required to fill in something on the page, but all individual fields are optional. We're trying to work out how to display validation when the user fills in nothing.

I think the main options are:

1. Show error summary but no fields in error
2. Show error summary and all possible fields in error
3. A new design? orange fields!?

Each has downsides:

• If we don't show anything in error users might get confused as to why the summary is there.
• If we show all possible fields in error, then users might incorrectly think that they need to fill them all in.

Compounding this is that I think this is a really hard one to test in usability testing - it's very uncommon to fill in nothing. If people have suggestions for testing this, I'd be open to it.

---

It would be good for the design system to have guidance on this. If the option 1 is selected, then examples of what errors should look like when you don't link to something.

[adamsilver]

What about the following...

1. Show users a list of checkboxes. At least one must be selected.

2. Clicking a checkbox reveals a text box. Which is required at this point.

[terrysimpson99]

Please help us interpret the guidance. The guidance says "If your page includes breadcrumbs or a back link, place it below these, but above the h1." We use section numbers ('Section X of Y'). We don't know whether a section number should be treated as a breadcrumb (and hence above the summary) or should be treated as h1 (and hence below). I mocked up the two options below. Which one should it be?

---

[NickColley]

@terrysimpson99 In this scenario you can keep the caption next to the heading (your second option), which is consistent with the guidance on captions hope this helps.

There's also a specific example for this were they're grouped: https://design-system.service.gov.uk/patterns/question-pages/#using-progress-indicators

[terrysimpson99]

Thanks very much. That's a great answer.

[adamsilver]

My service has a few pages where the user is required to fill in something on the page, but all individual fields are optional. We're trying to work out how to display validation when the user fills in nothing.

@edwardhorsford I've been thinking about this more since you originally raised this. I would group all the fields in a fieldset and then have one error for the group when all are empty like this:

[terrysimpson99]

Here is another example

[mbillingsleyCO]

Hi everyone, does anyone know what the error messaging style is to prompt users to add something to a list?

Do you start with the verb 'add/enter x information', or is it a statement stating the rule 'There must be x' ?

[lfdebrux]

I'm looking at whether we can use the error summary component to replace some instances where we have an error message not linked to a field in a form.

For instance, on our service if a user requests a password reset they are sent an email with a link that is valid for 24 hours. If they click that link after 24 hours has elapsed, they are sent to the page where they originally requested a password reset, with the following error message:

I was a bit surprised to see that with the error summary component in govuk-frontend the error text is not red if there isn't a link.

It's not a big deal in this use case, but it looks inconsistent to me, especially when side by side with an error item with a link (obviously that is an unusual use case).

[timpaul]

Hi @lfdebrux.

The error component is only intended for informing users about form errors. For the use case you described we'd probably suggest using some kind of alert component.

There's an alert component in the Design System backlog. It's not yet been prioritised for development, but you might find some useful examples there.

[zaizous]

Hi all, I have a question about the error summary component that I hope you can help with. A recent accessibility audit at DVSA pointed out an issue in relation to the heading level hierarchy as we use this component with H2 above the page H1 and below the back link.

GDS guidance on this is confusing, as the example provided uses H2 above H1 but also advises the following "Put the error summary at the top of the main container. If your page includes breadcrumbs or a back link, place it below these, but above the h1.".

My question is if it would be acceptable to use span instead of h2 or if this would be a problem with the screenreaders to use the markup below?

<div class="validation-summary" role="alert" id="validationSummary" tabindex="-1">
    <span class="govuk-heading-m">There is a problem</span>
    <ol class="validation-summary__list">
        <li class="validation-summary__item"><a href="#">error message</a>
        </li>
    </ol>
</div>

I have seen hmrc using it here https://www.access.service.gov.uk/login/signin/creds, but I am not sure what would be the correct approach from an accessibility point of view.

[hannalaakso]

@zaizous Thanks for your comment.

The heading order on a page should reflect the content. This is explained well by Léonie Watson in this discussion:

The key thing is to make sure the heading hierarchy reflects the structure of the content. For headings to be usable they need to be a representation of the visual structure. [...] If the <h4> preceeds the <h3> only to achieve some visual effect, then it fails SC1.3.1 under F43 (due to using structural markup in a way that does not represent relationships in the content)

(emphasis mine)

There is some more discussion about this by the Paciello Group here (under "Skipped heading levels").

However if there was evidence that the current error summary heading structure created problems for users we would review the markup. The error summary heading structure (with <h2> in error summary above <h1>) has also been externally audited for accessibility and confirmed to meet WCAG 2.1AA.

In answer to your question, using <span> to markup a heading would fail WCAG 2.1 1.3.1 which requires that "information, structure, and relationships conveyed through presentation can be programmatically determined". This is also discussed in the same Paciello Group article (under "Heading-like text that isn’t marked up as headings").

[zaizous]

Thanks @hannalaakso, this was very helpful.

[dashouse]

Hello 👋

Can anyone confirm the benefits of using the error summary when there is only a single error?

My assumption is that it's probably better for a consistent experience, no matter how many errors a user encounters. However I'd be keen to (remember) any other benefits I may have forgotten :)

[cjforms]

hi @dashouse

Rather the opposite, in fact.

I happened to be part of the team that created the error summary in the first place, way back in 2015. It's stuck in my memory - I hope, I may have got confused - because it was shortly before the big Kingsway fire that unexpectedly closed Aviation House in Kingsway just before Easter and it stayed closed for quite a long time.

The previous error message component didn't work for screen reader users, and @ljwatson was helping us out with testing. All the heavy lifting was done by @gemmaleigh and I was trying to help out by doing some content design. Or maybe I was just being interfering. Opinions may differ!

At the time, I was pretty much convinced - and I think that Léonie and Gemma agreed - that we didn't need an error summary on pages where there was only a single error. However, the content design of the page was bogging us down, and meanwhile we had something out there that was plain not working. So it was rather urgent to get it out.

The compromise we agreed was that we'd release the new error messaging with a summary for all pages. It was way better than something that didn't work at all, it handled all the cases, and it's proven not to be disastrous for the special case of a page with a single error.

But I've always wondered when the team would have a chance to go back and re-think, especially as the 'begin prototyping with one thing per page' idea has become a core part of GDS and NHS Digital advice (and mine).

[dashouse]

Thanks as always @cjforms. I am working on a different Design System now and we are only showing a summary if there is more than one error (also doesn't appear to be disastrous) so I was just keen to understand the origins. Thanks!