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

[simonwhatley]

At the time of writing, this page has two types of banners: Brexit/transition and 'national applicability' (a.k.a. excluded nations)

https://www.gov.uk/guidance/pet-travel-to-europe-after-brexit

Brexit / transition

National applicability (a.k.a. excluded nations)

We also have 'withdrawn' notices on GOV.UK, and 'history mode' that relates to policies from a previous government. For example, this page has both:

https://www.gov.uk/government/publications/development-and-flood-risk-practice-guide-planning-policy-statement-25

Withdrawn notice

History mode

[timpaul]

A different kind of alert. Overlays content, and is dismissable

[vickytnz]

Summarising a discussion on slack this morning around messages notifying a successful action like this:

• make the banner the focus as per the error summary component, for example role="alert" tabindex="-1" (maybe usedata-module="govuk-error-summary" )
• add a prefix to the page title as per the error summary component to be Success: or similar
• the banner won't need any assistive text about 'Success' as this is in the title of the page

[timpaul]

@DebsDee did a fantastic detailed investigation into this component back in September 2019. More details here: https://gist.github.com/DebsDee/2b137bf424f4aa18401fda1062c322b5

[adamsilver]

Examples from the Apply for teacher training services. Design is meant to be as similar to the error summary as possible.

Same font size, in black (except for link text).

Status information

When it's just a piece of information, or a status, not focused on page load and is in blue.

Here's another:

Confirmation flash messages

When it's in response to a user action, like a flash message (like the error summary), it should be green if it's successful and red if something went wrong (but that might just be the error summary in lots/most of cases).

In this case, the component should be focused on page load and have all the same attributes as the error summary.

If you refresh the page or navigate away and come back the message should be gone.

[adamsilver]

@timpaul we need to consider rules around showing multiple notifications at a time. Here’s what I reckon:

1. Show one notification at at time.

2. An ‘alert’ should trump any existing ‘status’ notification. For the service I’m working on the ‘Note added’ alert should temporarily replace the ‘Respond to application’ status banner (see screenshot).

3. If you have 2 (or more) status banners then collapse them into 1 and change the message.

One problem with (2) is that it may mean there’s more of a reason to add a dismiss link (like we've been debating about). Otherwise the user has to refresh the page/navigate away to be able to respond to the application.

[edwardhorsford]

@adamsilver I'd be tempted to keep both - looking at your screenshot, I think you ave 1 banner and 1 alert. I think services should limit to 1 alert, but hiding permanent page content when it's visible seems weird.

[mgifford]

Coming from here https://github.com/alphagov/govuk-design-system-backlog/issues/71#issuecomment-648855225

Thought it would be useful to have this reminder about Alerts in general and how to document how to manage the documentation. Here's a reference from Australia https://designsystem.gov.au/components/page-alerts/rationale/

[mviegasb]

The Home Office design system also has an 'alerts' component: https://design.homeoffice.gov.uk/components/alerts

[hannalaakso]

The Design System team had a notification banner component (preview) internally reviewed for accessibility. The component has not yet been published and is being reviewed by the Working Group.

The feedback from the accessibility review is posted is below and it’s really interesting. The Design System team have not yet worked on next steps for the feedback but meanwhile we wanted to post it here for visibility.

Differentiating between the types of banners

Not being able to programmatically tell the difference between the green and red banners, and not being able to visually tell the difference between the three banners (by users who can’t perceive the colour difference) was flagged as a concern (could fail https://www.w3.org/TR/WCAG21/#use-of-color). It could be interpreted that the colour is not just an enhancement here but that there’s a wider meaning attached to it. If we wanted to find out more about the significance of the colour here we could test the banners by making them all use the same border colour to see if they still work for users.

The content needs to make the it clear that they are different - this is what our guidance already asks teams to do. However we need to make sure that this is done consistently (https://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-consistent-functionality.html) - we could consider asking teams to use words like “Important” or “Warning” for the red banner, for example, to make that distinction so that users know throughout the service whether they are dealing with a green/success or red/error banner, for instance.

Suggested solution to the above which wouldn't rely on content alone could be using an icon and/or hidden text like the warning text component does. Or just having some extra text that’s part of the component visible in the banner.

Blue banner

role="region" seems to work okay and was picked up as a region on NVDA and FF, Jaws and IE11 when we tested it. Anika and Richard were happy with the approach of role=region being used for the least important type of notification (however see open question on blue banner below).

However the positioning of the role=region banner could cause screen reader users to miss it entirely in the list of headings. This is because screen reader users often navigate to the level 1 headings first, then 2 etc. Both NVDA and Jaws will in this scenario continue to cycle through the headings from the where the current focus is (ie. the h1), instead of the top of the page.

Positioning (in general)

Our guidance to position banners at the top of the page was flagged as something that would give users a lot to scroll past on mobile devices before even getting to the main page heading, for instance with the long covid banner we have on the current preview example.

Dynamic banners

We don't have guidance about this at the moment but if teams added a banner to the page dynamically and moved focus to it, the moving of focus has to be in response to a user interaction and that they expect the focus to move. If it's not, the banner should use aria-live instead of role=alert- shifting the focus without aria-livewhere user doesn't expect it is a WCAG fail (edited) 

Remove aria-labelledby

It’s recommended we remove aria-labelledby from the markup for the red and the green banners as they’re not landmarks (https://www.w3.org/TR/wai-aria-1.1/#landmark_roles) and therefore the label will never be read out (the same actually applies to our current error summary).

Open question on blue banner (from Hanna after review):

I was reading https://www.w3.org/WAI/WCAG21/Techniques/failures/F103 after the review. As I understand it the blue banner will be considered a “status message” as it doesn’t get focused and is likely to include some of the following: “information to the user on the outcome of an action, the state of an application, the progress of a process”. Following the WCAG guidance I wonder if we should be adding role=“status” to the blue message instead of role="region"? I don’t know if @selfthinker has any thoughts on this? I might well have missed something.

[selfthinker]

Thanks for writing that summary @hannalaakso. I've got a few notes...

the positioning [...] could cause screen reader users to miss it entirely in the list of headings

Clarification: When a screen reader user uses the list of headings they would not miss it, the banner heading will be in that list. But it's likely they would miss it if they skip to the h1 first as a means to skip to the main content and then start reading the content from there (or skip to the next heading etc).

would give users a lot to scroll past on mobile devices

I would add that users who zoom into the page or magnify the screen are also affected by this.

If it's not [in response to a user interaction], the banner should use aria-live instead of role=alert- shifting the focus without aria-livewhere user doesn't expect it is a WCAG fail

Correction: The problem is the shifting of the focus and does not depend on the aria attributes used. Shifting the focus when the user doesn't expect it is always a fail ("unless the user has been advised of the behavior before using the component"). The way to fix that is to either use role=alert (or probably some other roles) or aria-live but without the focus change. But removing the focus would be problematic for mobile, zoom and magnifier users as that means they might miss the message.

As I understand it the blue banner will be considered a “status message” as it doesn’t get focused and is likely to include some of the following: “information to the user on the outcome of an action, the state of an application, the progress of a process”.

To my understanding the blue banners will not be used for status messages. My understanding was that it was always there independent of user interactions, states and progress?

But that points to another problem I had pointed out during our meeting. We need to test these messages within the context of how they will be used. The testing out of context for something that is part of a user interaction or a user journey is mostly futile. For that reason I cannot really answer your question. You might be right, you might be wrong, it depends on the context.

[joelanman]

not being able to visually tell the difference between the three banners

Have we considered icons to help with this? Not sure there are words that we can mandate that will always work well in every context?

I think the question is how vital is it to tell the difference between the types of banner, or is the colour more of an enhancement of the content.

[edwardhorsford]

The content needs to make the it clear that they are different - this is what our guidance already asks teams to do. However we need to make sure that this is done consistently - we could consider asking teams to use words like “Important” or “Warning” for the red banner, for example, to make that distinction so that users know throughout the service whether they are dealing with a green or red banner, for instance.

I think our aim should be that the alert messages are understood by users, and that that understanding can be achieved regardless of colour.

Put another way: add content / icons whatever if it it's needed for users to understand the alert, not just so users can know "whether they are dealing with a green or red banner, for instance". Knowing the colour of the banner shouldn't be the aim - the aim should be understanding of the alert.

[hannalaakso]

@edwardhorsford

Knowing the colour of the banner shouldn't be the aim - the aim should be understanding of the alert.

This gets interesting when trying to comply with https://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-consistent-functionality.html. It seems to me that user will need to know which type of banner (green/success, red/error) they're dealing with so that the user can

rely heavily on their familiarity with

the component when interpreting it - in this case I think the user needs to be able to understand that this is the same "green/success" banner they might have encountered earlier in the service journey.

[christopherthomasdesign]

GOV.UK Design System working group review

Representatives from the GOV.UK Design System working group reviewed a new 'notification banner’ component in August 2020.

All members in the group agreed that the component met the criteria for a new inclusion in the Design System.

The working group also made the following recommendations.

Scope of the component

There was a range of feedback on the scope of the component and how it relates to other components in the Design System. The main themes were:

• unclear distinction between the ‘success’ variant of the notification banner and the existing ‘panel’ component
• unclear distinction between the ‘error’ variant of the notification banner and the existing ‘error summary’ component
• possible confusion with the 'warning text’ component
• whether banners with ‘alert’ behaviour (i.e. taking focus on page load and using role=alert) are sufficiently different in behaviour to be a separate ‘alert’ component

As there isn’t clear consensus on how best to fit the component with existing ones , the Design System team will decide on a way forward for the first iteration of the component. We'll focus on causing least disruption for teams and reducing the chance of having to reverse a decision (i.e. deprecating a component then find we actually need it later).

Guidance

• 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

Design

• Explore use of icons or other visual indicators (such as consistent content) to make the difference between the notification banner variants clearer

Code

• Create nunjucks macros for the component
• Remove aria-labelledby from the markup for the red and the green banners as they’re not landmarks
• Explain what the different role= attributes do in the code comments because it’s not clear to everyone

Next steps

Based on this feedback the GOV.UK Design System team have agreed to:

• Decide on what the notification banner does or does not replace
• Explore use of icons or other visual indicators for notification banners
• Draft a new version of the notification banner guidance incorporating the working group's feedback
• Publish the first version of the component and guidance

[adamsilver]

We have iterated our use of notifications that are based on the status of the system.

Iteration 1: blue banner above the h1

We also tried with a button inside like this:

We found that some users didn't spot the banner which we thought might be some sort of banner blindness.

Iteration 2: remove banner and put below h1

This worked better than the banner but we still found some users missed it.

Iteration 3: add h2 and use inset text component

Then we changed to this and haven't seen any users miss it. This is what we've settled on.

[vanitabarrett]

Accessibility review

The Design System team took the latest iteration of the notification banner for an internal accessibility review. We were hoping to have addressed some of the feedback we had from the last accessibility review.

Differentiating between the types of banners

The last accessibility review raised concerns about being unable to programatically and visually tell the difference between the types of banners, especially by users who can’t perceive the colour difference. Following that feedback, we have changed the design so that each banner has a title (defaults: “Important”, “Success”, “Error”). This content means the banner no longer relies solely on colour to convey meaning.

Blue banner

As mentioned at the previous review, a navigation banner at the top of the page (above the page title) could cause screenreader users to miss it entirely if they choose to navigate to the first H1 and then continue to navigate through the page.

Autofocus

For dynamic banners which are added as a result of user interaction, we move focus to the banner. It was agreed that this is the correct thing to do as it will make the new banner clear to users who would otherwise not spot the banner appearing at the top of the page (e.g: screenreader users, users on a mobile device, and users using screen magnifiers)

We currently set role=‘alert’ and tabindex=‘-1’ so that we can focus the banner using JavaScript (we need both due to a bug with some screenreader, Anika thought this might be Voiceover on Mac/iOS). Tabindex -1 allows us to set focus programatically, but means that if a user navigates away from the banner they are unable to tab back to it. This probably isn't an issue as the banner isn't really an interactive element, but it's something to keep an eye out for in user research.

We also keep the tabindex="-1" after the banner has lost focus, which means that clicking on the banner gives it a yellow focus border. This could be confusing as it implies it's interactive (see the above point).

Action: test removing the tabindex onBlur so the banner doesn't display a focus outline. Confirm whether Voiceover on Mac/iOs requires role=‘alert’ and focus. Make note of any instances of a user trying to tab back to the notification banner / think it's an interactive element in user research.

Use of multiple banners

Using multiple banners of the same type is not advised - we would recommend merging banners of the same type into one. Although rare, there may be cases where multiple banners of different types are used on the same page.

We tested a scenario with a success banner and an error summary (also uses role=alert and has auto-focus behaviour). In this example, the error summary was above the success banner and was auto-focused. Admittedly, the scenario we tested in was a bit of a stretch and unlikely to be something you would want to do in a real service. The main concern is that users may see the first banner and skip past it if there is a clear action within that banner. This is especially true for an error summary which links to an input field.

Action: consider interaction between error summary and notification banner - should they ever be used together? More generally, observe how users interact with the notification banner in user research - do they skip straight to main content if there is a clear action, or continue to navigate through the page.

Styling

The notification banner has title text which uses a heading element. There are examples where you might want to style banner content underneath this (paragraph) so that it looks like a heading. It’s always a bit tricky when elements look like something they’re not. This probably wouldn’t be an issue for screenreader users specifically, but is likely to affect people who change the look of sites with custom stylesheets (or those who have disabled CSS).

[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: https://github.com/DFE-Digital/publish-teacher-training-prototype/pull/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?