Also known as: alert
An on-screen alert to notify users that something important has happened.
The text was updated successfully, but these errors were encountered:
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.
@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.
@stevenaproctor thanks for the points.
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.
We could remove the buttons from the scope of this component, then consider updates to the 'Button' component separately in the future.
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;
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.
Across all the references linked to in the description, I found the following themes:
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.
Rural payments, Pay, Notify and Registers all also use tick and cross icons to indicate success and failure.
Colour is used fairly consistently.
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.
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
Information you need before using this page
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
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
ARIA attributes should be added to give alerts accessible names.
Those that need immediate attention should have a role of alert.
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.
The following people helped out with this (thanks!) and all have experience of implementing this pattern:
@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.
@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.
@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
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
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".
Coming from here #71 (comment)
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/
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.
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.
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)
It’s recommended we remove
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
Thanks for writing that summary @hannalaakso. I've got a few notes...
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).
I would add that users who zoom into the page or magnify the screen are also affected by this.
Correction: The problem is the shifting of the focus and does not depend on the
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.
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.
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.
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
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.
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:
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).
Based on this feedback the GOV.UK Design System team have agreed to:
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.
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.
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.
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 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.
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).
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
What we decided and what has changed
How we went about building it
How you can help our ongoing user research
This component is experimental because:
Share your research or feedback by commenting on this issue or propose a change – read more about how to propose changes in GitHub
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.
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.
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.
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 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.