Some form components trigger an error immediately onBlur when a field is blank

[humancompanion-usds]

Description

The a11y specialists have noted that screen reader users often tab through all the fields in a form to learn how long the form is and what is going to be asked of them. When doing that it would appear that some of our components throw an immediate error when tabbing out of the field to the next field. We recently addressed this, I believe, in the Memorable Date component as that component is comprised of 3 text-input fields.

This issue is to track investigating which of our components throw an immediate error when you leave the field (onBlur) and what it would take to prevent that. If this is just a method we provide, can we not throw an error until a certain number of characters are entered, for example in a text-input or textarea, or a a change made, for example in a select, radio, or checkbox.

Details

The outcome of this work should be a recommendation on what the lift would be to accommodate the accessibility concerns here and not throw an error on a blank field or field that has not been changed.

[taylorkaren]

Any work for the Forms Library team related to this issue would be done on the When should errors be triggered? ticket

[caw310]

Moving back to reviewed/needs prioritizing since we do not have a11y support at this time.

[humancompanion-usds]

@ndsprinkle - Picking up our conversation over in this issue, which is more relevant.

it seems like one of the concerns is that we fire the validation even when nothing is typed in the field. This is definitely true because all that needs to happen to be marked as "touched" is for the onBlur function to fire, which fires in any situation where the field goes from having focus to losing focus. It doesn't matter what is typed in the field.

Can we undo that, or prevent that, without upsetting everything else? By that I mean, can we change "touched" to mean some characters were entered into the field or the field was set to a non-default value (to handle selects)? I'd like to address the concerns in this issue but I'd also like to retain the functionality of immediate feedback to the user when an error has been rectified.

I also assume that this strange combination of onBlur and "touched" was done so that you wouldn't get annoying, immediate validation until you try to move away from the field.

I agree and would want to retain that but change the definition of "touched".

But when a user hits the back button, we don't want to stop them from going back

That's still relevant and still the correct behavior.

B.J. added a function for onMouseDown so that he could do something before onClick happens. In this case, he's essentially blocking (and resetting, maybe on accident) onBlur for all the fields on the page when you hit the back button.

What if Back wasn't a button and was instead a link? Would that uncomplicate matters a bit when combined with changing the definition of "touched"?

@caw310 and @PSIEBENLIST - Let's get the devs on both teams together to talk through this issue and the requested changes to the va-button-pair component. I'd like to make and validate these changes this quarter.

[ndsprinkle]

@humancompanion-usds These are great questions that I don't fully know the answer to. I definitely agree with getting the teams together and talking about it. I think it's worth some digging and experimenting to figure out if stuff breaks and how much stuff breaks.

In general, I feel like this should be possible, but as always, the forms library supports a bunch of custom functionality around validation and transition functions (like useCustomScrollAndFocus) that teams have used over the years and my fear would be the custom stuff stops working as originally intended.

[jamigibbs]

The forms library team and DS team discussed this and the main issue is the "required" error displaying before content has been entered into the fields. The design system components rely on the required (boolean) prop to be set in order to display that error so we think this is something that the forms library team will need to control (not anything the component needs to update).

For our part though, the Design System team should check the form components to make sure this isn't an issue with the component itself. The way we should be testing them is:

1. not enter any values into the fields
2. tab through the field(s)

If an error/validation displays (required or otherwise), we should flag this as an issue that the DS team should investigate because we want users to be able tab through form fields if they have not entered anything yet without getting a validation error.

cc @caw310

[humancompanion-usds]

@ndsprinkle and @rhasselle-oddball - Do we want to look into fixing this issue when we fix this one? department-of-veterans-affairs/va.gov-team#5190

[rhasselle-oddball]

Fixed in https://app.zenhub.com/workspaces/vagov-product-team-forms-634853151f5c6000165942bc/issues/gh/department-of-veterans-affairs/va.gov-team-forms/434

Fixed for all forms - generic RJSF onBlur handler for fields to no longer set fields to touched if a field is empty on the first pass, which will in turn not trigger validation.

[humancompanion-usds]

Yay!