Notification banner

[govuk-design-system]

Also known as: alert

What

An on-screen alert to notify users that something important has happened.

For example:

• an action was successful
• an action was not successful
• a deadline is imminent
• a payment is overdue

Why

Anything else

• Digital Marketplace has a version of this called "Notification banner" Notification banners: Digital Marketplace style guide (also used on GOV.UK Notify and GOV.UK Publisher)
• DWP has a version of this Alerts and notifications: DWP design patterns
• Rural payments has a version of this Alerts: Rural Payments Styleguide
• HMRC has a version of this called "Overdue" Overdue: HMRC design patterns
• GOV.UK Publishing has a similar component used to let users know the status of documents, for example if they're withdrawn by the current government notice, also banner
• Read discussion about "Warnings, notifications and alerts" Dropbox paper
• Read discussion about "in-service notifications & alerts" Dropbox paper

[NickColley]

One proposal:

The alert component would be a top level component that is generic that does not have any understanding of the context it's used in.

This component would have different variants called 'danger', 'success'. Similar to the digital marketplace implementation.

We'd then move 'Error summary' component and 'Confirmation panel' component into patterns that use 'danger' variant and 'success' variant respectively.

[stevenaproctor]

@NickColley Should we be using colour, especially red, this way? Because red can cause stress, especially when a page loads and it is not connected to what they have done, like the way error messages work. Should we be recommending this amount of red?

There is something about the red button that would make me think I was doing something destructive like deleting something.

I realise the red, amber, green and blue are enhancements and everything should make sense without the colour so should not affect people who are colour blind.

[NickColley]

@stevenaproctor thanks for the points. 👍 💯

Should we be using colour, especially red, this way?

One nice thing about the current error summary component is that it indicates it's usage in the name, so you wouldn't accidentally use it to display something that is not an error.

If we were to do this I suspect we'd need to be careful with the guidance to help people choose the right variant for their use case.

In terms of increased amount of colour, we could consider doing alerts more in line with the current error summary component, which does not change the text colour.

There is something about the red button that would make me think I was doing something destructive like deleting something.

We could remove the buttons from the scope of this component, then consider updates to the 'Button' component separately in the future.

[markhurrell]

I'd like to do some work with making these more consistent and maybe reducing them down to a simpler set of banners and notifications, but I'm not sure they would make sense as a single component;

1. I think the information design requirements for the different types of banners and notifications probably needs to be different, they're doing different things and have different urgencies. An error message preventing you from submitting a form probably needs be different from a generic site-wide notification banner, or a success confirmation with follow actions.
2. There's probably a case that the markup would need to be different for different types of notification too? or at least have very different levels of urgency within the document tree?

[tombye]

I've done some research on this pattern that might prove useful, talking to the designers involved and looking through the references in the description.

Themes

Across all the references linked to in the description, I found the following themes:

Visual patterns

Alerts in transactions have a complete solid border:

Most of those on content pages just have a different background colour:

GOV.UK has a variant called notice, like those for transactions but with a thiner border:

Those on dashboards have a border on the left, like the inset text pattern, with a background colour to match the border but with a lighter hue.

Icons

Rural payments, Pay, Notify and Registers all also use tick and cross icons to indicate success and failure.

Colour

Colour is used fairly consistently.

• red indicates something that should be acted on immediately or will have an immediate effect on the user
• green indicates success
• blue marks the banner information as context for that in the page and not based on a user action

Where orange is used, the intention was often unclear and in a few place it indicated the alert contained information which should just be part of the page content.

Types of alert

The types of alert seem tied to the type of page.

Description	Type of page	Services
Your action was successful	Transaction	Digital Marketplace, Notify, Rural Payments (DEFRA)
Your action was not successful	Transaction	Digital Marketplace, Notify, Rural Payments (DEFRA)
Information you need before using this page	Transaction	Digital Marketplace
Information you need before reading this page	Content	Digital Marketplace, GOV.UK
Notice about the service process	Dashboard	Prepare for Universal Credit (DWP)
Notice to draw attention to a part of the page	Dashboard	Bereavement Support Payment (DWP), Rural Payments (DWP)

Your action was successful

Your action was not successful

This banner should include information (including links) on how to be successful.

Digital Marketplace, Registers, Notify and Pay use this to ask users to confirm an action and so include
a button for that confirmation.

Information you need before using this page

Use cases

Digital Marketplace have forms with pre-filled fields, based on information users have already given them. They use a banner to let users know where the answers came from.

Information you need before reading this page

Use cases

Digital Marketplace show services that are no longer available to buy on their procurement frameworks. They use this banner to mark them as different to those still available.

GOV.UK display policies from previous governments and so use this banner to mark them as different from those of the current government.

Notice about the service process

Notice to draw attention to a part of a dashboard

Technical implementation

ARIA use

ARIA attributes should be added to give alerts accessible names.

Those that need immediate attention should have a role of alert.

Other alerts should have a role of region and an aria-label attribute set to "notice".

Focus

Alerts that need immediate attention should have focus shifted to them when the page loads or when the action they relate to completes, if that doesn't involve a new load.

Additional notes

@abbott567 mentioned the DWP patterns page isn't used for all DWP projects, just the 'Prepare for Universal Credit' service.

The following people helped out with this (thanks!) and all have experience of implementing this pattern:

• @quis
• @laurenceberry
• @NickColley
• @ralph-hawkins
• @abbott567
• @fofr
• @jonheslop

[stevenaproctor]

@tombye Impressively comprehensive.

Red works well with validation error messages and similar use cases where the red is connected to something you have just done. But when a page, like a dashboard, loads and the red is there in a notice it could inadvertently cause people stress. It might not be obvious why the red is there.

If the colour is there to draw attention, all notices could be blue to signify 'this is a notice' without any extra effects. The meaning will come from the content.

If we want to use red, we could be less intrusive but still effective. We want people to do something but we do not want to cause stress. In the HMRC example mentioned in the description, the alert would be better and more accessible without all the red content.

In the example under 'Your action was not successful' with the red button, you cannot say no. And it is not as accessible as it could be.

The button is not linked to the question in any obvious way and the label does not make sense out of context. It could say 'Yes, delete testing' and you could have another button that says 'No, do not delete testing' but that is not how yes-no questions are usually handled.

This type of action would be more accessible as a separate, standard yes-no question with radio buttons. The screen would come immediately after someone tries to delete something.

[abbott567]

@stevenaproctor we had a blue notice at the top in bereavement to inform agents that a claim needed attention, and it tanked in session after session. Agents just couldn’t see it. It was like they were banner blind or something. Literally staring at the page and not seeing it for minutes. Was really awkward.

However, the red notice in the example above about the overpayments did work, they saw that straight away. But we do use it sparingly. It’s only ever shown under really niche conditions. Most people will never see it.

I think that we’d have to be really careful in the guidance if we go ahead, because alerts are really open to being abused when plain content may actually be better.

[stevenaproctor]

@abbott567 I have no doubt it draws people's attention and guidance about when to use and not to use it is super important.

When we tested alerts in tax credits, people rarely saw those at the top of the screen because they do look a little banner-y. But when we moved them further down the screen so they were under the <h1> they were seen more often that not.

[quis]

@tombye This is an awesome piece of work 👏

[abbott567]

For anyone interested, this is the blue banner we tried that nobody saw. I can't remember the exact figures, but it was definitely more than 50% of people that didn't interact with it or even see it.

It got to the point where we literally sat in research sessions saying "Do you think there might be anything else you need to do on this page?" and... nothing. haha

[kr8n3r]

Alert/Notification on Civil service Live

[joelanman]

Civil Service Learning

[joelanman]

Also Civil Service Learning

[jfranciswebdesign]

Companies House

We're testing this pattern as part of our accounts filing service (currently in Beta) - testing well with all users so far (including those reliant on assistive technology and those with low digital skills) - the common reactions tend to be "Yes, I've seen this type of thing before" or "Yes, that's what I expected".

[CharlotteDowns]

Release of notification banner using the experimental label

The notification banner component has been published in the Design System as experimental because more research is needed to validate it.

The notification banner component tells the user about something they need to know about, but that’s not directly related to the page content.

Problems we looked to solve

• Clarify what to do with service-wide 'status' messaging in banners (e.g. coronavirus delays).
• Add clearer guidance and examples about how to handle multiple banners on a page.
• Provide clearer guidance on placement of notification banners.
• Explain how long notification banners should persist in different contexts.
• Explore use of icons or other visual indicators (such as consistent content) to make the difference between the notification banner variants clearer.

What we decided and what has changed

• The notification banner can be used to tell the user about a problem that’s affecting the service as a whole (for example, delays in processing applications because of an emergency). We retired the 'Understand the impact of an emergency on your service' pattern as we believe the following use cases can be covered by a notification banner component:
  • This service is affected by a pandemic
  • This service is closing soon
  • We'll soon be making changes to this service, and everyone needs to know about them
• Within the guidance for the notification banner we advise services to use notification banners sparingly. Notification banners of the same type on the same page should be combined into a single notification banner with the message re-written. If you need to show notification banners of different types on the same page, place the more immediately relevant banner at the top. See visual examples of positioning a notification banner in the guidance.
• We decided not to publish a red banner variation as errors usually require on the page actions where the error summary component is more appropriate. For service errors we suggest using the problem with the service page.
• Position a notification banner immediately before the page h1. The notification banner should be the same width as the page content to provide a consistent experience for users across services.
• We found that across one thing per page user journeys, notification banners did not need to persist across different pages. We advise to remove banners when they are no longer useful.
• Icons are helpful but take up a lot of space within the notification banner and can have different meanings depending on the context, we decided to use a piece of content instead.
• We decided to go with 1 component, not 2. Neutral / success banners have a lot more in common than not, separating them could be confusing and make the banner variations harder to find. The ‘alert’ behaviour is configurable as we cannot assume all ‘success’ banners need to have alert behaviour applied to them, although this will be on as default.

How we went about building it

• We took the notification banner to the GOV.UK Design System working group as a draft example for approval.
• We took the notification banner component to test with the GDS Accessibility team and assistive technologies three times. After each visit we made improvements both to the html markup and focusing using javascript.
• We carried out further accessibility testing within the Design System team.
• We are taking the notification banner to user research in December 2020.

How you can help our ongoing user research

This component is experimental because:

• we have confidence that it works in some contexts, but not in others
• we're actively asking for service teams who try it in new contexts to share their results with us
• we would like teams to contribute specific examples of red banners if they have used them so we can learn about other use cases

Share your research or feedback by commenting on this issue or propose a change – read more about how to propose changes in GitHub

[neil-holroyd]

We are looking at using the notification banner in this scenario but in DWP we have the summary panel at the top of the page which is the same colour. Any thoughts on avoiding this – alternative default colour for pages where there are two elements like this maybe?

[CharlotteDowns]

What an interesting challenge @neil-holroyd and thank you for raising it. Could you help me learn a little bit more about the service and the action in which you want the user to take? I guess you may not have implemented the notification banner component yet but it would be really helpful to get some user research to strengthen this need. If teams are facing a similar design scenario we'd be interested to hear about it too.

[neil-holroyd]

Hi @CharlotteDowns, I have been head down in a new project so apologies for the late reply. The service is a caseload management system for NSJSA. This instance occurs when a customer calls and the agent goes to their claim but it is allocated to a different service centre – then they can only do any updates on the case if they allocate it to themselves. Upon doing so the actions for this page will be in view. At the moment this is a prototype and we have done a playback to the user groups. All feedback has been positive overall. At the time of testing we didn't have a UR in place so it was more of a general playback. This summary panel is quite a commonly used mechanism across WA so this may occur across a few services.

[RosieClayton]

In December 2020 the Design System team tested the notification banner, in 8 usability sessions, with users who use assistive technology. We used the Blue Badge journey to test the banner alongside other components and patterns.

We tested with participants who had little or no vision and used screen readers (NVDA and Jaws) and ZoomText. Some participants had dyslexia and used Text-to-Speech and Read and Write Gold.

First important Banner
The first important banner was seen and referred to as 'covid message'

Success Banner (which appeared above the first important banner when users added healthcare professional details)

The success banner read out well for one participant, who was an NVDA user "you heard it say alert successfully added. I didn’t have to do anything which was double confirmation. When they get screen readers to read that out that is doubly handy." Participants had both the completed tag and the success banner to confirm that had added details successfully. P5 expected the success banner after adding contact details.

Second Important banner

Second important message (Covid and disposal of blue badge) Most participants missed the second banner. One participant who was a screen reader user skipped straight past the message as she wanted to move on the next task and was going through the headings. Two participants said they missed the additional information when they were asked about it. One participant thought the information inside the banner was in the wrong place and should have had a more prominent place at the end of a journey.

[CharlotteDowns]

The Department For Education used the notification banner in a prototype journey for teacher training, but it was consistently missed by lots of of users, so they’re removing it: DFE-Digital/publish-teacher-training-prototype#99

[markhemsux]

Hi all, we are currently developing a feature on UC that allows agents to create and modify diary schedules and there are some instances where we believe the most suitable component to use would be a red version of the notification banner. For example, if the user tries to save a schedule a red banner would allow us to clearly indicate that there has been an error related to the save action. Importantly, this can not be achieved using the error validation summary component as that contains a link to fix the error on the page, which is not appropriate in this case. For this case we are A. Informing the user that the save action has failed and why, and B. Presenting three possible ways to fix the problem (clicking on the link to review the conflicting schedule, changing the dates, or setting the ad hoc checkbox to override the existing schedule). Please see the attached design for context.

.

[dominichurst-ur]

Has anyone looked into a floating notification banner? So for context below the banner is several blocks of content that can grow depending on the user. Sometimes this means the notification banner scrolls off the screen. In our case, the notification banner has a link and in UR we have seen users failing to see the link as it is now off-screen.
I am not aware of floating/ sticky elements other than a sticky header which wasnt progressed - https://technology.blog.gov.uk/2018/05/21/sticky-elements-functionality-and-accessibility-testing/

[andrewhick]

Is the link in the green notification box (under 'reacting to something the user has done') meant to be green (#00703c)?

This seems to contradict the design system guidance that links should be blue by default and I can't find any discussion about these links needing to be green anywhere.

[christopherthomasdesign]

Hi @andrewhick, thanks for getting in touch. It is intentional. Like with the error summary, we style the links to be in a consistent colour with the border. This is to make the components more cohesive visually – we found that using blue links with a different border colour made them look a bit broken. We're confident that the context, colouring and underlines used still make it clear enough that it's a link, and haven't observed any issues specifically with links in usability testing to date.

[CharlotteDowns]

We have removed the 'Experimental' tag from components, patterns, and guidance in the Design System 😌.

The tag was being used on the notification banner component to raise awareness that more research is needed to validate it. However, we recently published new guidance on how to share findings from users which we hope will make it easier to collect more information about how our Design System is being used across services.

If your team has used this component please let us know 💪🏻.

[LGrace8]

I'm using the notification success banner as part of a workflow, and I've been testing on various screen readers - all fine except for Talkback on Android, We've been unable to shift the focus state to the message inside the banner to read. Has anyone else had experience with this? May be worth mentioning we are using role="alert" so the focus shifts on page load

[realitydust]

Is role=alert necessary for the error summary context if that pattern includes moving focus to the notification banner?

[GrahamHNHSBSA]

I'm Graham from NHS BSA. I'm a designer working on an overseas service application. My users are trained internal users. We are improving the accessibility and experience of their tool. May I ask the folks here if they are currently researching or exploring the use of a 'close' function in this notification component?

The Gov UK guidance states further research required to find out "whether it’s sometimes helpful to allow users to dismiss notifications, and how to do this"

Anyone?

Thanks

[RyanHobbsCO]

Hi,

We have just had an accessibility audit carried out and an issue has been raised surrounding the hierarchical structure when the notification banner is used and subsequently failing WCAG 1.3.1. Has there been any more research done surrounding the issue this proposes when a H2 is used before the H1 and the issues for screen reader users?

Thanks,
Ryan

[joelanman]

@RyanHobbsCO the audit is wrong, there is no requirement to start with H1 - wcag even has an example (see example 2 here)

https://www.w3.org/TR/WCAG20-TECHS/H42.html

[RyanHobbsCO]

Hi Joe, I did see this example but under the heading hierarchy within the WCAG guidelines it does state you should be starting with a H1 and I could see this raise as a potential issue at the bottom of the design guide for the notification banner so wondered if there was an more thought around if this is the best solution for the component.

[joelanman]

Where does it say that in the wcag guidance sorry?

[RyanHobbsCO]

Hi Jon, I was going off a different W3C page that you've linked. However, I've re-read our Audit and looks like the issue isn't with the initial heading so I don't need to worry about my original comment. Thanks for commenting back.