[USABILITY]: Form error handling when users press Continue button should be reviewed

[Mottie]

Issue

This issue was opened to address this issue across all forms. The content of this issue was copied from #1705 (closed) which was only specifically addressing form 526EZ.

The error handling when users press the Continue button was flagged by the VA 508 office during an audit. They said the expected behavior was to focus the first form field in error when users press Continue and one or more fields have errors.

I (Trevor Pierce) checked this behavior on other forms, and it seems consistent that we require users to press TAB to move from the form to the first input in error on other forms, so it seems our behavior on the 526 disability increase form is consistent. I am putting this issue in as a way to review that behavior and start a larger conversation if necessary.

Environment

• Windows 7 64 Bit Enterprise Edition SP1
• Google Chrome
• JAWS 2018.0

---

---

@1Copenut commented on Mon Sep 24 2018

@djmunoz1 I logged an issue with the US Forms Library repo ( usds/us-forms-system#278 ) about error handling, that seems to line up with this issue. Please advise if you'd like to leave this open, or close it and manage another way.

@Mottie commented on Wed Sep 18 2019

Slack response from Trevor Pierce

Hi team.
I reviewed the ticket and this is standard behavior on all of our forms, to require users to press TAB after pressing Continue to get to the first invalid required field. I reached out to the VA 508 team and referenced the new ticket to get a final conclusion.
I’ll set a todo to circle back with them next week and let you know.
No action is required until we have guidance.

@YanaRoy commented on Tue Oct 1 2019

@1Copenut following up: is this still blocked?

@1Copenut commented on Tue Oct 1 2019

@YanaRoy Yes, this is a wider issue that would affect all of our forms. What do you think about closing this item for the 526 specifically and opening a new issue ticket for exploration? It might be better served that way, because any change will be sitewide.

[ndsprinkle]

I tested this on a couple different forms and the behavior is consistent and as described in this ticket. While the page does scroll to focus on the "top" error field, it does not actually go inside of the field to allow immediate editing. Tab has to be pressed first in order to begin editing the field. To me, this is less of an "issue" and more of just a different approach, but I'm not a designer and it may be make way more sense for some users if it actually scopes into the error field instead of just scrolling to it.

@luke-gcio As this is now, this is a global form issue and not specific to any one of our forms or any other form. Should we hand this off to another team? I can also look into the code to see how quick of a fix this would be. It may be as simple as going to the place in the code where we scroll to the field and simply telling it to also begin editing the field.

[ndsprinkle]

Digging in a little more, it may be as easy as modifying the scrollToFirstError function. However, there are two different versions of this function and it is used in several locations, so it may not be as easy as I hope. Going to continue to investigate.

[Mottie]

I think you should discuss this in the accessibility channel. The focus is on the div surrounding the form element. It includes the label/legend, error message and form elements.

• This div is focused, but the outline isn't visible; maybe it just needs some css?
• Or, maybe the focus should be moved to the label/legend?

Either way, I think the scrollToFirstError located in src/platform/utilities/ui/ isn't being used, so it can be ignored (or removed?)

[ndsprinkle]

Maybe I'm confused by the ticket or confused by what you are saying, but are you saying this isn't actually a decided issue, rather a proposed situation to look in to? I was assuming it was already decided to be an issue and that someone had determined that the focus was supposed to be inside of the field. That being said, I don't think there is any CSS change to be made, just simply switching the focus to the input. Regardless, this ticket really sounds like not our problem more and more, especially if it's requiring discussions with designers/accessibility about the global form system.

[jenstrickland]

I defer to @1Copenut on this, since he initiated this issue.

As I understand this:
The VA 508 Office "said the expected behavior was to focus the first form field in error when users press Continue and one or more fields have errors." This reads as the focus should be on the form input field and display the error of the field so the user may correct and understand what the error is. If it is possible to correct this in your implementation, it should be corrected.

[ndsprinkle]

@jenstrickland Okay, thank you for explaining. That clarifies a lot!

[1Copenut]

We should maintain the current behavior of keeping focus on the Continue button, and having users press TAB to move to the first input with an error. I referenced notes from the January meeting with the VA 508 office, item number 4 from Points of Discussion:

The error handling question in our forms [USABILITY]: Form error handling when users press Continue button should be reviewed - #2533 came up during the discussion. VA 508 office mentioned the peer group didn't have strong feelings about leaving focus on the Continue button and requiring users to press TAB to move to the first error, or moving automatically. Given the precedent for leaving focus on the Continue button, we should keep an active listen for feedback and revisit if users identify it as a problem spot.

I'm fully on board with working up a proof of concept and researching it with users if there's interest. Pinging @CrystabelReiter && @emilywaggoner for visibility.

[jenstrickland]

@1Copenut - upon that first TAB, should the focus be on the input field, the label, or the container? I also think the error styling should be present on the related field. I couldn't find error state documented for form controls in the design system https://design.va.gov/components/form-controls.

[1Copenut]

@jenstrickland Upon pressing TAB the first time, we are setting focus in the first input with an error. This seems right to me for current behavior. Users get the full label + error message read back.

Good call that the error handling isn't documented in the form controls. That's something we should fill in.