Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce border width of form inputs in the error state #1870

Merged
merged 4 commits into from
Jul 21, 2020

Conversation

36degrees
Copy link
Contributor

@36degrees 36degrees commented Jul 17, 2020

Reduce border width of form inputs in error state.

We rely on the input border getting thicker in order to meet WCAG 2.1 1.4.11: Non-text Contrast.

However, 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 (alongside the addition of the yellow outline). The contrast between the red and the black is only 2.75:1, so the change in state from error to focused may not be perceivable by some users.

Reduce the error border width on inputs down to 2px, which is the same as the normal border width for a form input.

As the border width is now no thicker than the normal border width, remove the overrides that suppress the focus state's box shadow from errored inputs.

For components with multiple inputs, like the date input,this change does make it even more important to ensure that the error message clearly explains which field has the error. Although fields with an error continue to be differentiated from others by the thicker left border and the bold error text, the red border around the specific input can now only be seen as an enhancement. We are updating the documentation in the Design System to stress the importance of being explicit about which field an error message relates to.

Remove the border from the file input in its error state, aligning it with radios / checkboxes, where the error state is indicated by the red left-hand border on the form group and the error message.

Finally, deprecate $govuk-border-width-form-element-error to be removed in v4.0.

Fixes #1820

Before After
localhost_3000_examples_error-summary localhost_3000_examples_error-summary (1)

Chris Thomas and others added 3 commits July 17, 2020 13:43
We rely on the input border getting thicker when an input is focused [1] in order to meet WCAG 2.1 1.4.11: Non-text Contrast for the focus state. [2]

However, 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 (alongside the addition of the yellow outline). The contrast between the red and the black is only 2.75:1, so the change in state from error to focused may not be perceivable by some users.

Reduce the error border width on inputs down to 2px, which is the same as the normal border width for a form input.

As the border width is now no thicker than the normal border width, remove the overrides that suppress the focus state's box shadow from errored inputs.

For components with multiple inputs, like the date input,this change does make it even more important to ensure that the error message clearly explains which field has the error. Although fields with an error continue to be differentiated from others by the thicker left border and the bold error text, the red border around the specific input can now only be seen as an enhancement. We are updating the documentation in the Design System to stress the importance of being explicit about which field an error message relates to. [3]

[1]: https://design-system.service.gov.uk/get-started/focus-states/
[2]: https://www.w3.org/TR/WCAG21/#non-text-contrast
[3]: alphagov/govuk-design-system#1302
Align the error state of the file input component to that of radios / checkboxes, where the error state is indicated by the red left-hand border on the form group and the error message.
The border width of form elements in their error state (`$govuk-border-width-form-element-error`) is now the same as form elements in their normal state (`$govuk-border-width-form-element`) – both are 2px.

This isn't something we think users need to be able to configure, and we don't really want the complexity of trying to support different border widths for the error state (for example, the box shadow override that we removed in 6bdca06 would need to be conditionally added if the user changed $govuk-border-width-form-element in order to maintain a consistent focus state).

We'll remove this setting entirely in v4.0, the next breaking release.
@govuk-design-system-ci govuk-design-system-ci temporarily deployed to govuk-frontend-review-pr-1870 July 17, 2020 12:48 Inactive
@36degrees 36degrees marked this pull request as ready for review July 17, 2020 14:49
Copy link
Contributor

@vanitabarrett vanitabarrett left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good - I think it just needs an entry in the Changelog?

@govuk-design-system-ci govuk-design-system-ci temporarily deployed to govuk-frontend-review-pr-1870 July 21, 2020 09:28 Inactive
@EoinShaughnessy
Copy link
Contributor

@vanitabarrett Was $govuk-border-width-form-element-error the thing that changed borders from red to black/an override/something else entirely?

@vanitabarrett
Copy link
Contributor

@EoinShaughnessy No, it set the width of the border rather than the colour.

We used to make the border of an element thicker when it was in an error state, but we now don't (it keeps it's original thinner border size) - you can see the difference in the screenshots in the PR description. Ollie's explanation in the PR covers the reason why we've made this change. I think to really summarise it down to one or two lines, it's because we need the focus state to be made clear to users - a change from red border to black border isn't enough, but a change from red to black PLUS a change in border thickness is. Because the focus state already has a thick border, we need to reduce the size of the error border so there's a visible change in thickness when someone focuses on an input in error state.

Not sure if that helps or is more confusing! Happy to jump on a call to explain.

@EoinShaughnessy
Copy link
Contributor

@vanitabarrett It helps, thanks! I drew on your explanation to update our release notes about why we made these changes. Not sure what I've added is definitely what we want, though - probably a good one to chat about at our catchup tomorrow!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

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