Consider changing or removing focus state for error summary and notification banner

[36degrees]

What

Decide on whether the notification banner, which is automatically focused when the page loads (for the error and success variants), should have a focus state and what it should look like.

Decide whether the same treatment should be applied to the existing error summary component which behaves in the same way.

Why

We need to understand whether WCAG 2.1 1.4.11 Non-text contrast applies to this element. It's programatically focused on page load, but is not keyboard-operable – once focus has left the error summary, you cannot navigate back to it using the keyboard.

The proposed 2.4.11 focus visible (at time of writing) explicitly only applies to keyboard operable controls:

Some elements can take focus (such as the target of a skip link), however, it is only when the element is operable by keyboard controls that this criterion applies.

If this logic applies to 1.4.11, then the focus state of the error summary / notification banner does not need to meet contrast – in which case, is the yellow outline actually helpful? Or should we remove it entirely?

If the focus state does need to meet contrast, then we need to revisit the focus state for both the error summary and the new notification banner component.

Further detail

The error summary currently has a yellow outline when focused.

The proposed notification banner component will also take focus on page load (for the error and success variants), so we will presumably want to use the same approach.

However, the yellow outline does not meet 3:1 colour contrast against the white background. Other components use a black border when focused (which then means it meets contrast), but because the error summary is focused on page load we want to preserve the border colour so that it suggests an error / success state as appropriate.

Done when

• Understand how WCAG 2.4.11 applies to the notification banner and error summary components
• Decide on focus state for notification banner
• Decide on focus state for error summary

[36degrees]

Relevant discussion on w3c/wcag: w3c/wcag#1401

[christopherthomasdesign]

Had a think and a good read of the related WCAG criteria.

Does WCAG 2.1 1.4.11 Non-text contrast apply to these elements?

From my interpretation, it does not apply. This is because I don't interpret an error sumary or notification banner to be an 'active user interface component' or 'control' in the way WCAG usually describes them.

I think:

• a ‘user interface component’ is something that is perceived by users as a single control for a distinct function (a bit different to how we define components)
• an 'active user interface component' is one that is actionable, like a checkbox or input field

I don’t think either error summary or notification banner fit into this category. They often contain links, which could be argued as controls. But not the banners themselves – it's just a box that surrounds some content.

If this interpretation is correct, what should we do next?

Given the above, it seems to me that the yellow border isn't needed.

We programmatically give the error summary keyboard focus on page load so it's more likely to be the thing perceived first by users – seen first on page, content tab-able first, read first by screen readers. I'm not sure removing the yellow border stops any of that from happening.

But it does sit in a bit of a grey area because it technically is focused even if it's not focusable.

I'm going to ask for further opinions from the cross-gov design system and accessibility communities as the related criteria aren't 100% clear!

[kellylee-gds]

@36degrees @christopherthomasdesign can you add the "why", "who needs to know about this", and "done whens" sections to this card please? Thank you

[adamsilver]

The way I think of it is this: is the focus outline helpful to the user?

I think it is because it makes it clear which element is in focus so that as a keyboard user I can work out where the focus will go next.

Without the focus outline, I cannot be sure where focus is and so as a keyboard user I won't easily be able to see where the focus will go.

Edit: interestingly the link to a Github comment works in much the same way. Here's a link to this comment:
#1936 (comment)

[christopherthomasdesign]

Thanks @adamsilver, I see your point. I don't know if users think that's what the yellow border means, I haven't seen any evidence either way. Have you come across anything?

I'm leaning towards keeping the yellow focus border for now (on error summary and on the new notification banner when released), as we don't know of it causing any issues.

We're currently planning user research where we should take the opportunity to test some banners without the focus border and see what impact it has. I'd prefer to remove it if it's not helping, because I generally don't think we should add visual elements unless they're clearly needed. If we find it is needed, we'll have to revisit the design – as Ollie says above, it currently doesn't have enough contrast with the un-focused state.

[36degrees]

If we find it is needed, we'll have to revisit the design – as Ollie says above, it currently doesn't have enough contrast with the un-focused state.

Yeah, definitely – if it is useful then it should be available to everyone, not just those who can perceive the yellow outline against a white background.

[edwardhorsford]

My view would be that it might not be required, but we've got a pattern of yellow border for where focus is, so unless there's a good reason not to, should keep it.

[adamsilver]

Thanks @adamsilver, I see your point. I don't know if users think that's what the yellow border means, I haven't seen any evidence either way. Have you come across anything?

@christopherthomasdesign I haven't observed users understanding it or not understanding the yellow border. Would be good to watch a bunch of keyboard/screen reader users using the same interface with and without it.

[christopherthomasdesign]

So, to summarise, we're going to:

• keep the border for now, seeing it as an enhancement for users that can see and understand it
• do some user research with/without the border to see what impact it has

[selfthinker]

My view would be that it might not be required, but we've got a pattern of yellow border for where focus is, so unless there's a good reason not to, should keep it.

Although, we don't have that pattern consistently. When we use jump links / anchor links, we don't show the focus of the target either.

For example, the heading "Linking from the error summary to each answer" on that section on the error summary page is not highlighted, even though it is focussed.