[A11y] [VPAT] 3.3.2 Labels or Instructions - Playground>OpenAI - Form does not indicate required fields

[dave-gus]

Description:
Required form fields are not indicated

Steps to Reproduce:

Create a Search project and go to the Search project homepage (ex: https://my-elasticsearch-project-eca3d1.kb.eu-west-1.aws.qa.elastic.cloud/app/elasticsearch)

1. In left nav, select 'Playground'
2. Under 'Connect to LLM', select 'Connect'
3. In the side panel, select 'OpenAI'
4. To see required fields, click 'Save' button

BEFORE:

AFTER:

WCAG or Vendor Guidance (optional)

• Understanding SC 3.3.2 Labels or Instructions (Level A)

[alexwizp]

@dave-gus @1Copenut Could you please provide more context about your expectations here? I'm not sure we should highlight the field in red upon opening the form. Additionally, I've noticed the same pattern being used in other places.

Screen.Recording.2024-07-15.at.13.02.22.mov

Screen.Recording.2024-07-15.at.13.13.52.mov

[dave-gus]

@dave-gus @1Copenut Could you please provide more context about your expectations here? I'm not sure we should highlight the field in red upon opening the form. Additionally, I've noticed the same pattern being used in other places.

Screen.Recording.2024-07-15.at.13.02.22.mov
Screen.Recording.2024-07-15.at.13.13.52.mov

@alexwizp There is no indication that certain form fields are required -- either asterisks next to required form field labels or an alert that all fields are required (if that is the case).

[alexwizp]

@dave-gus I understand what you mean. I just wanted to say that it's a common issue across most forms in Kibana. I think we should agree on how it should be for all places, rather than focusing on this specific one. Maybe someone from EUI can help us figure out how it should look, or we could fix it on the EUI side to standardize it in one place.

@1Copenut, @cee-chen please help us with that.

[dave-gus]

@dave-gus I understand what you mean. I just wanted to say that it's a common issue across most forms in Kibana. I think we should agree on how it should be for all places, rather than focusing on this specific one. Maybe someone from EUI can help us figure out how it should look, or we could fix it on the EUI side to standardize it in one place.

@1Copenut, @cee-chen please help us with that.

@alexwizp Ah, yes. Good point.

[1Copenut]

@dave-gus I had a very similar issue in Observability: #195038

I think these are similar enough that we need to push for a design review of the UI and guidance on what an accepted pattern should be. I see a few things that need considered and probably updated:

• Where to set focus when these modals open
• The way we identify visually and semantically which fields are required, and which are optional
• Error handling (is it after the Submit press, or before, or something else?)

[dave-gus]

@dave-gus I had a very similar issue in Observability: elastic/kibana#195038

I think these are similar enough that we need to push for a design review of the UI and guidance on what an accepted pattern should be. I see a few things that need considered and probably updated:

• Where to set focus when these modals open
• The way we identify visually and semantically which fields are required, and which are optional
• Error handling (is it after the Submit press, or before, or something else?)

If error message(s) is/are presented after submitting, error must be made clear by screen reader and focus should move back to the field (or first field, if there are multiple) where the error occurred. I read an interesting study that inline validation actually causes more errors and increases the time it takes to fill out a form.

[1Copenut]

I read an interesting study that inline validation actually causes more errors and increases the time it takes to fill out a form.

I agree, inline validation is annoying. Especially for a screen reader. In my own testing, inline routines would break in over the next field being announced to tell me about the error, which was overly confusing. Worse yet, some inputs would remove the error when the field regained focus.

I'm reaching out to the UX Patterns Working Group to see if we can set some guidelines around this pattern.

[alexwizp]

@1Copenut @dave-gus temporary moved to Blocked till getting clarification from the EUI team

[1Copenut]

Adding @kyrspl and @MichaelMarcialis for visibility. I feel this would be a good pattern candidate!

[MichaelMarcialis]

Thanks for the ping, @1Copenut! This has been a topic that comes back up every now and again. I think most recently, I was talking to @julianrosado about this. The current pattern in Kibana, Cloud Portal, etc. is to identify optional form controls (via the labelAppend prop for EuiFormRow components). I believe the original reason for this approach was due to the fact that the majority of form controls across these platforms are required. The supplementary labeling of optional fields only seemed the sensible direction to take to avoid visually overwhelming users with "required" indicators in every form.

That being said, the current direction is not without caveats. As @dave-gus shows in the screenshots above, in situations where all form controls are required, there is no opposing "optional" indicator to help inform users what is or isn't required. Instead, it just appears that the entire form is devoid of any direction (even though in reality, everything is required).

Also, if I'm reading the 3.3.2 success criteria correctly, our current approach would not pass. Is that correct? If so, I agree that we should indeed discuss this in the pattern working group and come up with a solution that passes the success criteria but also doesn't visually overwhelm users in forms with majority required fields. I'll add this topic to the next working group agenda.