Present notification banner at the accessibility clinic

[hannalaakso]

What

We're taking the notification banner to the GDS Accessibility clinic for testing it with different assistive technologies. We've also got a few specific questions we want to ask at the clinic (see below) (part of #1935)

Why

To get feedback on accessibility related points and to test against different AT.

Who needs to know about this

Hanna; Ollie's kindly offered to present what we have at the clinic but other people from the team might also want to join the call.

Done when

• We've created realistic example pages to demonstrate the component
• We've presented what we have at the clinic
• We've made notes of any interesting findings and documented follow up actions
• We've posted a summary of the feedback on Notification banner govuk-design-system-backlog#2

Further detail

Questions to ask

• What happens if there is more than one element on the page with role="alert"?
• Which screen readers require the focus to be set on the component, in addition to already setting role="alert"? (We'd quite like to document the detail in the code)
• Is it okay on occasion to apply the DS heading styles to a <p> tag? (link to example)
• Does it make sense that we set the tabindex to -1, not 0? What's the user experience like if the notification banner is focused on page load and then the user wants to tab back to it as an interactive element but it's no longer there? (The error summary contains links so those can still be navigated to later on)
• Would it make sense to remove the tabindex after focusing?

[vanitabarrett]

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.

As we've recently got AssistivLabs, we focused more on the specific questions we had rather than general testing. It might be a good idea to do some general testing of the banners with other screenreaders. In this review, we mainly used JAWS.

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. When testing with Windows High Contrast mode, we were unable to differentiate between the different colours (as expected), but the title text provides context instead.

Action: If we want to test this further, we could consider intentionally adding examples of notification banners using the same / wrong colour for their content to user research and observing the impact that had on users (e.g: using a red banner for a success message).

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.

Positioning (in general)

A previous review flagged that banners positioned at the top of the page will give users a lot to scroll past, especially on mobile devices and those using screen magnifiers, before they reach the main page content. This isn’t a scenario which came up in the second round of testing as banner content was kept fairly short.

Action: consider mentioning recommended length of content and/or use of multiple banners in the notification banner guidance

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).

[vanitabarrett]

Presenting the notification banner at the accessibility clinic has been completed. I've created follow-up cards for any further work:

Test notification banner with assistive technologies (#2010)
Address notification banner accessibility concerns (#2011)