Page Notice
A custom landmark which appears prominently at the top of the page.
Last updated
A custom landmark which appears prominently at the top of the page.
Last updated
User notification which appears prominently at the top of the page, above the main content.
In order of priority, from high to low, a page notice is classified as either:
attention
confirmation
information
Page-notices may be rendered server-side and visible at page load time or, in a single page app environment, they might instead be triggered on the client after some user action.
Composite patterns containing Page Notices are:
A page notice must appear above the main page content, and above the fold if possible.
A page must have only one page notice visible at any time.
Page notice must not rely on colour alone to convey meaning or tone.
Page notice should use an icon to further assist conveying meaning & tone.
Page notice may optionally contain a button to dismiss and hide the notice.
Page notice may optionally contain any number of call to action links or buttons.
An attention notice must receive keyboard focus if rendered on the server. In some cases we do this for client-side rendered notices too (e.g. if the notice contains a call to action link or button).
Critical error notices must be announced on page load (achieved via focus management).
All client-side changes must be announced (achieved via live-region for non critical notices).
Page notice must be available in screen reader list of regions or landmarks.
A page notice has 4 key pieces of content: icon, heading, copy and call to action link or button (optional).
To aid discoverability of such important content for assistive technology, we make the page notice a landmark, using the <section> tag and region role.
The page notice will not appear in the screen reader's list of landmarks until we assign it an accessible label. We will fix that in a little while.
Adding a tabindex value of -1 allows programmatic keyboard focus on a high-priority page notice.
NOTE: You may wish to apply the tabindex attribute in a progressively enhanced manner with JavaScript instead.
Notices rendered or updated on the client must exist within a "live-region".
Assistive technology will now announce any client-side changes to content within the live-region element.
We will begin by structuring the notice into 3 parts: header, main & footer.
The SVG icon fits into the header slot. It has an aria-label value of "Attention", "Confirmation" or "Information".
The heading element can be used to as the label for the landmark region, fixing the issue mentioned previously.
Finally, any call to action link or button can be placed into the footer slot.
Low priority notices such as confirmation and information should never receive keyboard focus.
All high-priority page notices rendered on the server should receive keyboard focus.
Some high-priority notices rendered on the client should receive keyboard focus. Typically these are notices that contain an interactive call to action that helps resolve the issue.
Experience the pattern in action on our companion .
Examine the required markup structure in the .
View a fully styled example on our .
