Forms - Error messaging

[k9dh3zij]

Hello,

We're looking at form error message patterns for the next version of the Design System, and have identified two alternatives.

We'd like to hear your feedback before we make a decision, and in particular:

• Which version do you prefer and why?
• Are there any concerns that we haven't covered below?
• Are there any improvements that you would suggest?

Please could you comment below by Sunday March 14th.

Thank you!

Version 1

Live example

• https://tq0oog.axshare.com

Short description

• Pressing submit generates a list of errors above the form.
• Focus automatically moves to the error list and the screen scrolls up.
• Clicking on any of the errors in the list takes the user to the respective form field.

Advantages

• Behaviour is consistent with the majority of web applications.
• Users are explicitly made aware that there are errors in the form.

Concerns

• We are 'hijacking' the browser scroll.

---

Version 2

Live example

• https://dyli21.axshare.com

Short description

• Pressing submit generates a list of errors underneath the form submit button.
• The form submit button is disabled until the user corrects all errors.
• We do not move the form focus - no automatic scrolling takes place.
• Clicking on any of the errors in the list takes the user to the respective form field.

Advantages

• We do not interfere with the browser scroll.

Concerns

• Is disabling the button accessible? There is no recourse if a screen reader user misses the errors (especially as we are not moving the focus), which could leave some screen reader users stuck.
• In certain edge cases (example below) if a long list of errors is generated it can push the submit button below the fold and no errors will be visible. Some users may be uncertain as to what has happened, unless they scroll up or down and get to an error. However, they may still not see all errors.

v2 edge case:
Live demo: https://2fxn09.axshare.com

[ghost]

Version 1 - consistency with expected / learned behaviour user's have from existing web sites and applications wins for me. Maybe have the error messages at the top clearer e.g. called out in a red box like GOV.UK design system: https://design-system.service.gov.uk/components/error-summary/

Version 2 - even though I knew it was coming, I completely missed the error message. I looked at top of the page - there was nothing there.

I'm not worried about the intercepted browser scroll - I've seen this before in these situations.

Also, 2010 called, they want their rounded input boxes back. Can we dial back the border radius? Makes all inputs look like buttons to me.

[thyhjwb6]

Something I have been thinking about is whether the issues discussed:

1. A feeling of getting lost on the form (unable to find what's wrong with the inputs)
2. Movement of fields with errors

are symptomatic of another issue which might be that the forms are too long for a single step. GDS have a one thing per page rule which we could borrow some thinking from.

they’re better at handling things like errors

It does not necessarily have to be a hard and fast rule but maybe the expectation of many fields per page is not realistic. If a long form is divided into multiple steps then perhaps some of the usability issues we have discussed then go away.

[jpveooys]

Another vote for option 1 here. I agree with the other comments above, but I'd also add that it presents a logical workflow i.e. work through all the errors in the original order of the fields and then click the submit button. With option 2, while there are links to the fields with errors, the user may just scroll up and attempt to fix the fields with errors in reverse order and things may be more awkward.

Another thing is that if it were a multi-step form and both steps didn't fit in the viewport vertically, you'd also expect to be taken to the top of the second step when proceeding to it and so option 1 would be consistent with that.

If directly scrolling the browser is a concern, perhaps navigating to an anchor would be an alternative?

Last thing I'd add is that it could be the case that even smaller forms sometimes don't fit in the viewport due to screen resolution or size combined with the page layout.

[k9dh3zij]

Thank you all for the feedback.
We'll go with version 1 for now and will tweak to incorporate some of the feedback we got.

There will be more opportunity for feedback on functionality and visual design when we invite feedback on Forms v3, in a few weeks' time.

Thanks again.