Support required form fields that only trigger invalid state after 1st user interaction/blur event

[cee-chen]

We've recently had requests from @academo, @bfishel, and @paul-tavares on the subject of required form fields. Currently, EUI does not do any specific management around field requirements - when users pass in the required attribute, they get the default browser behavior which unfortunately flags empty inputs as :invalid on initial page load (past related issue: #4710).

For full context, historically (per @cchaos) we've had far more use-cases where either the entire form is requred or there are more required than optional fields. In those scenarios, leaving required fields as the default and instead marking optional fields where they exist has been the preferred UX (example article). We've also generally preferred whole form validation that occur on final submit.

However, I still think this is fairly useful functionality (which we can/should of course still provide UX guidance around) that I've wanted in the past while working on Enterprise Search, so I did a quick spike attempt at baking in required behavior that only triggered invalid states after the first user blur event. I also wanted the required UX to integrate into EuiFormRow and color the label + automatically display an error message, so I did a little extra work around that.

You can check out the PR here: #5244

And you can also test on the PR staging:

• https://eui.elastic.co/pr_5244/#/forms/form-controls
• https://eui.elastic.co/pr_5244/#/forms/form-layouts
• https://eui.elastic.co/pr_5244/#/forms/form-validation

Here's a few unknowns left from my spike that I would love to get feedback on from the folks who want this feature as well as our designers/product stakeholders:

• Component support/use-cases
• Prop API naming
• Form label required indicator (if any)

I'll start separate comments below for each topic to help with threading and resolution. Feel free to start more if you can think of other potential issues or discussion points!

[cee-chen]

Component support & use cases

Here are the components that I updated to use the new required logic, and were super easy to update/required no extra code to get working:

• EuiFieldText
• EuiFieldSearch
• EuiFieldNumber
• EuiFieldPassword
• EuiSelect
• EuiTextArea

Here are the remaining components that will likely not have immediate required functionality:

• EuiFilePicker
  • This component should technically be supported by the required attribute (and also supports isInvalid as a prop), but due to the underlying markup of the component it will take some extra effort to get it working
• EuiDatePicker
  • Per MDN, this component should technically be supported by the required attribute, but due to the underlying 3rd party library component, it will take some extra effort to get working
• EuiSuperDatePicker
  • This component is extremely complex and additionally comes with its own internal validation so I'm honestly not clear on how we would go about supporting required behavior here or if it's even needed. I'd love to get feedback on what teams, if any, would want this.
• EuiCheckbox/EuiCheckboxGroup/EuiSwitch/EuiRadio/EuiRadioGroup
  • Per MDN, these are components that technically are supported by the required attribute - but currently none of the check/radio components support any kind of OOTB validation state or error messaging as far as I'm aware, so I'm not totally clear on how I'd go about implementing required behavior here. We would likely need to re-evaluate how we approach validating checkboxes & radios in the first place before being able to do this
• EuiSuperSelect
  • This is a fairly custom component without an underlying native select/usable input to hook into, so would need a custom effort/lift to get working. I'd like to hear how many teams would need this before investigating
• EuiComboBox
  • This is a fairly custom component without an underlying native select/usable input to hook into, so would need a custom effort/lift to get working. I'd like to hear how many teams would need this before investigating
• EuiRange, EuiDualRange, and EuiColorPicker
  • MDN notes these the underlying color and range inputs as not supporting the browser required attribute, so I don't think we should support these either, but would love to hear if folks feel otherwise
• EuiSelectable, EuiExpression, EuiFilterGroup, EuiSearchBar, EuiSuggest
  • These are not traditional input elements and have fairly specific use cases that likely don't belong in forms, and I don't think should support required behavior, but please chime in if you feel otherwise

@academo, @bfishel, @paul-tavares - please let me know whether this initial list would be immediately usable by your teams, and if not, what components from the 2nd list you would need!

[academo]

Thanks for the fast work you put on this functionality.

I'd say the initial list is great and already helps to reduce boirplate on the most basic forms.

We usually create most interfaces with items of the first list. Of course many or most the elements on the second list are also used.

[cee-chen]

Prop/API naming

This came up during our sync today when I demo'd my work and is very closely related to #4982. When I originally was spiking this out, I went with isRequired for symmetry with our existing isInvalid, isLoading, isClearable etc. type props. I also deliberately wanted to break away from the native required attribute because the UX itself is not the same as the default browser behavior (and for that reason I would push strongly against naming the new prop to just required as well).

However, I'm aware this does highlight some confusion as with our disabled/isDisabled props on buttons and some inputs/fields (the fact that we accept both and they essentially do the same thing as the native disabled). I do somewhat think per the above linked discussion that we appear to be moving towards isX naming, and that we can make it clear in our props documentation that isRequired does not 1:1 mimic required behavior.

@cchaos also suggested a more verbose API option, e.g. requiredAfterBlur or requiredOnBlur. Any thoughts or for/against opinions here?

[cchaos]

Sorry I didn't realize you were reference new functionality. If we're at that point, we should probably be discussing in the PR?

[cee-chen]

This discussion was originally opened for new functionality/to discuss the specific PR linked in the top-level description. It's also been threaded to discuss different parts of the PR (UX, implementation, scope, etc.); I don't think we need to move discussion away from here.

If the remaining sticking point is the prop API name, I would like to propose settling on requiredOnBlur for both EuiFormRow and all EuiField* type components, and moving the PR out of draft.

[cchaos]

If we support both requiredOnBlur and required on inputs, which one would take precedence?

[cee-chen]

required would. The underlying logic for requiredOnBlur primarily just adds the required attribute only after the first blur event, so it makes sense that required always being present takes precedence.

[cchaos]

Ok, sounds good

[cee-chen]

Form label required indicator

When I demo'd this today, I originally had a * indicator on the EuiFormRow label to note required state, e.g.:

I removed it after feedback from @cchaos that we don't necessarily want to enforce this indicator especially for forms where most or all fields are required. I wanted to start a discussion topic on it however since I believe @paul-tavares also voiced some strong opinions on UI/UX affordance for users before their submission.

FWIW, I do think it's fairly easy for devs to add their own * or (Required) text of their own in either EuiFormRow labels or helpTexts, so I'm relatively ambivalent on whether we bake something in or not, but would be interested in hearing everyone's thoughts.

[cchaos]

Keep the invalid state on page load as the required indicator

Here me out. I encountered this exact situation today where I added required to a text input that is empty on load which spun me into some thought.

Considering these 3 possible options, lets look at the different stages of the form (especially the kind that disables the submit button until all inputs are valid).

A. Leave as-is
B. Asterisk marking required
C. Invalidate only on blur

---

Page load

Comparing these three options, you could argue that the way it works now (A) is the most indicative of a field that is required as it is the most prominent indicator. The asterisk (B), while it has been a universal pattern to some, is pretty insignificant compared to the dark underline. It's also most obvious in (A) why the Save button is disabled, while in (C) with no feedback at all, it is not clear at all how the user should satisfy the form.

If that form was long and that save button is disabled with no indicators of required fields, could result in frustration and rage clicks.

---

On focus & filled

(A) and (C) are similar in that they enable the Save button and provide the focus indicator. However (B) still shows the asterisk which seems to be claiming attention from the user, but they've satisfied the form. If the form is valid, there's no longer need to show any indicator of possible error.

---

On error

All three are very similar in behavior in that, not only is the input indicating invalid, but so is the form label and the help text. If any form input has some type of validation but the consumer doesn't provide the user with why that that form is now invalid, that is a bigger problem.

---

On clear and then blur

Both (A) and (C) then have the same behavior. So it more comes down to how we want to handle the Page load scenario.

---

This is why I'd vote for leaving the behavior as it exists now (A). It satisfies both requests of indicating required fields without using an ambiguous character (which also needs a legend somewhere) while having a stronger actual error state and focus state. Basically the underline IS the required indicator.

If consumers are truly unhappy with this behavior for "reasons", then we suggest not using required at all but for checking the value of the input to satisfy validity.

[cee-chen]

I'll be honest that I'm not visually a fan of the current status quo/(A), but that's just my opinion and not a super strongly held one - I think others that originally posted the Slack discussions (e.g. @paul-tavares) probably feel more strongly and may have more nuanced thoughts there than I would.

I do want to put forth an accessibility reason for not maintaining the current required status quo however:

If consumers are truly unhappy with this behavior for "reasons", then we suggest not using required at all but for checking the value of the input to satisfy validity.

The required attribute does add extra functionality for screen reader: they'll audibly announce ahead of time that field is required when a user focuses into it. To tell devs to leave required off and to manually validate means that SR users lose this extra context. Devs can get around that by adding the aria-required attribute (which is what my PR does out-of-the-box), but let's be honest: how many devs are actually going to remember or go out of the way to do so? I'm personally going to guess very few, especially since there's no real way to automatically lint for it.

I see component libraries/design systems as a strong accessibility tool because they allow us to automatically handle or enforce accessibility and semantic best practices for devs behind the scenes and should make their lives easier while doing so. While native browser behavior and APIs improve every year, there's nevertheless plenty of reason to implement functionality that does better than the default. I see this behavior as one of those cases, it's clear from the many StackOverflow responses/upvotes that required registering as :invalid on page load is a mediocre user experience. I think offering an API in EUI to improve that experience while also providing better screen reader support is a gain - yes, a small one, but still a net benefit with a relatively low dev lift considering the work is already mostly done.