Focused inputs, textareas and file uploads may not have enough contrast when in the 'error' state

[36degrees]

For the input and textarea components, we rely on the input border getting thicker in order to meet WCAG 2.1 1.4.11: Non-text Contrast.

When the text input or textarea is in the error state, it already has a thicker border, and so the border only changes from red to black (in addition to the yellow outline). The contrast between the red and the black is only 2.75:1. EDIT: The contrast between the red (#d4351c) and black (#0b0c0c) is 4.03:1 – see #1820 (comment).

[christopherthomasdesign]

Had a little look into this.

I think we can mostly solve this problem by reducing the error border width on inputs down to 2px. Fields with an error would continue to be differentiated from others by the thicker left border and bold error text. The red colour of the input border can be seen as an enhancement, same as the other elements.

Then when you focus it, the existing wider black border makes it clear that it's being focused.

On the file upload error specifically, it seems like it would work fine without another border surrounding the button anyway:

The only example where I'm not sure this works is something like a date input. Here you can have a group of related fields that share an error message, but where only one field has an error. The current styling means the errored field is differentiated from others by a thicker border. That's lost when you use a 2px border, where only the red colour makes it different:

This might not be a big problem though. In the case above the error message specifically says which field has an error, and it is the only field without any saved data in it. You could add a bit of extra emphasis to the errored field by bolding its label though:

I guess I'm saying I think I've solved it but would be good to know:

• if there are things I haven't considered
• any impacts you could see these changes having on other patterns or components

[MalcolmVonMoJ]

@christopherthomasdesign
At the MoJ, we recently ran a batch of user testing with our errors not being highlighted at all (that is, it had the red bar and error text, but no red highlighting for the input box). Like this:

Our user researcher found the following:

Following an error message, users put the new answer in the wrong box on multiple occasions, could be the way the error messages are designed or the fact that there is already a lot of cognitive load on the user

If we reduce the thickness of the border to that of a normal input box, it would make the error state jump out less. This might lead to more instances of that found in our tests.

I appreciate we tested with black boxes not red, but as mentioned at the top, the contrast betwixt the two is not great.

[christopherthomasdesign]

Hi @MalcolmVonMoJ thanks for your comment, that's really useful. Would you be able to share a screenshot of what those errored fields look like in the context of a page? Thanks!

[MalcolmVonMoJ]

Here is the page as it appeared when the research was done, warts and all.

[MalcolmVonMoJ]

As I continue to work on our error messages, a thought occurred to me.

An error-state box, when focussed could reduce the thickness of the box. The change would be discernible through change in thickness, so the problem is solved.

This would make an error & focussed state similar thickness (minus yellow) to a non-error & non-focussed state, but you cannot go direct from one to the other, so no-one is relying on that being different.

Here are a few mockups I created to sanity-check the idea.

CSS changed from
.govuk-input--error { border: 4px solid #d4351c; }
to
.govuk-input--error { border: 2px solid #d4351c; outline: 2px solid #d4351c; }

With an extra bit of CSS for error and focussed for the design with the red box.
.govuk-input--error:focus { border: 2px solid #d4351c; }

[christopherthomasdesign]

Thanks again for your input @MalcolmVonMoJ! I've taken what you've done and looked at a number different border widths combinations to try solve this problem.

I prototyped different styles with some of the relevant components to quickly see how they'd work (username:design password:mess):

1. 2px error outline with 4px focus highlight
2. 4px error outline with 2px focus highlight
3. 4px error outline with 6px focus highlight
4. 4px error outline with 6px focus highlight in red
5. 6px error outline with 4px focus highlight

I'll outline a few thoughts about each below.

We'll probs have a team discussion to weigh up the pros and cons but any other input or feedback would be really useful.

1. 2px error outline with 4px focus highlight

The errored input doesn't contrast enough with standard inputs when not focused.

2. 4px error outline with 2px focus highlight

(I think this is closest to the ideas above). Errors stand out visually when not focused. When focused they lose contrast with other non-focused inputs as the yellow border is the only differentiator.

3. 4px error outline with 6px focus highlight

Focus state on errors has sufficient contrast with both the errored state and regular inputs. Visually very heavy but doesn't impede readability of the data users enter (though I say this as a fully sighted person).

4. 4px error outline with 6px focus highlight in red

Same pros and cons as above. These components would be the only cases where the focus state doesn't consist only of yellow and black. Given how much work went into defining the focus states it seems not worth diverging from if option 3 works.

5. 6px error outline with 4px focus highlight

Has enough contrast between all the states. Visually the 6px input border is a little inconsistent with the 5px error border on the left.

There are probably more ways to do this but these were the simplest I could think of. I'd say number 3 is my favoured option. It's in-keeping with the 'additive' nature of how we style focus states elsewhere. BUT very much open to any drawbacks I haven't thought of or new suggestions.

[36degrees]

My preference would be to avoid having a different focus state for inputs in the error state, which I think would point to option 1 or option 5. I think it's important to keep the 'rules' simple, for a couple of reasons:

1. For users, I'd be worried that it's not clear why the focus state is different for the field that's in the error state. Unless you're aware of the contrast requirement, it's hard to reason about why it behaves differently to the other fields.

   I suspect most users wouldn't notice, but wonder if this is the sort of thing that might be distracting for users with autism for example, who need consistency. (I have a very limited understanding in this area, and definitely nothing to back it up other than intuition, so very happy to be corrected!)

2. For service teams that are building their own components, the simpler the rules are the easier they are to follow when implementing focus states for their own components. We've definitely seen the new focus state implemented badly, and I think we could do a better job at providing guidance for it, but I still think there's less things to 'get wrong'.

Out of the two options, I think I'd lean towards 1, because the transitional behaviour ("borders get thicker when focused") is consistent with non-error'ed fields, as well as the individual error and focus states.

As previously mentioned, this does mean that in form groups with multiple fields (like the date input) the field cannot be visually identified unless you can perceive the difference between the black and the red, but in the examples in the Design System the error message should also identify which field is problematic.

Other cases where the error message can't provide that context seem to be hypothetical at this point, and I wonder whether we can mitigate against that by:

• ensuring that the guidance around the 'error state' explains its limitations and the fact that it can only ever be relied on as an enhancement alongside an error message
• making it really clear what the impact of this change is in the release notes

If we do end up preferring one of the options where the focus state is different for error'ed fields, I'd like us to try and do research with users with autism and/or engage with accessibility experts with a good understanding of how users with autism might be affected by the perceived inconsistency.

[christopherthomasdesign]

Had a chat with @timpaul about this and agree with your comments @36degrees. As a principle I think it makes sense to keep focus styles the same in all contexts if we can.

In light of that I've made a draft PR alphagov/govuk-design-system#1302 that:

• pulls in a branch of Frontend with 2px borders on inputs with errors
• includes a couple of changes to guidance on the Date input and Error message components

Have a look at the preview, particularly the changed guidance on:

• Date input
• Error message

Next steps, we probs need to:

• agree if we think this is the right approach for now
• think through how the frontend code should work for this (what I've done is a quick test tbh)
• work out when to release the changes – I think the proposed content changes could only come after the other changes are shipped in a release of frontend

[christopherthomasdesign]

Summary of team discussion 13 July 2020

• Get the guidance changes checked by a content designer
• Developer to pick up the Frontend branch and decide on implementation approach
• Look at how the borders and box shadows affect one another between the states to avoid jumpy page behaviour
• At the moment we don't think it's a breaking change so could ship these in the next release

[36degrees]

The contrast between the red and the black is only 2.75:1.

We've realised since shipping that this feature that this is incorrect – unfortunately this is based on the contrast between the 'old' red (#b10e1e) and black (#0b0c0c) which is 2.75:1.

The contrast between the current red (#d4351c) and black (#0b0c0c) is 4.03:1.

Although 4.03:1 technically meets the 3:1 ratio required for WCAG 2.1 1.4.11: Non-text Contrast, we still think that on balance this was the right change to make, an it does significantly improve the visibility of the focus state on fields in the error state.

We have since updated the order of the colour palettes in the settings file to make similar mistakes less likely (#1901).

I'll update the original message to reflect this.