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

[dave-gus]

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

The issue:
Required form fields are not indicated

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.

[1Copenut]

I agree with @dave-gus about the potential for confusion when all fields are required. In the past I've recommended adding a single line underneath the heading that states "All fields are required" and used required attributes on each input so screen readers would announce the label, input type, then required.

Adding "required" to each input feels overly heavy; more ink on the page than we need. By having a clear instruction statement, we can eliminate that momentary "what's required" cognitive load and hopefully reduce errors in submission.

[MichaelMarcialis]

@1Copenut, @dave-gus: A group of us (@mdefazio, @kyrspl, myself) met up today to discuss this issue. After reviewing the WCAG guidance, we thought the following pattern would make the most sense to use going forward:

• Always mark optional input fields via the labelAppend prop in a subdued text color on EuiFormRow components. All other forms of indicating optional (such as parenthetical text in the actual label) should be updated for consistency.

• If a form has only required fields (no optional fields) AND the form is a traditional linear experience where validation checks and messaging are provided on submission, display small paragraph text (nothing overly ornate) at the top of the form to indicate that "All fields are required".

• If a form has only required fields (no optional fields) AND the form is a non-traditional experience (such as Lens layer configurations, Discover/Dashboard inline editor, etc.), no additional affordance is necessary, as it would be strange to mark required fields in such instances.

• If the form has one or more optional fields, no additional affordance is necessary, beyond marking the optional fields.

Assuming you both agree with this guidance, we'd like to package it up as part of a larger set of form guidance and patterns in the working group. Let us know if ya'll have any questions or concerns. Thanks!

[alexwizp]

@MichaelMarcialis @cee-chen could you please update EUI docs with ^^^

[daveyholler]

@liranabn I've added this to the Search Relevance team project. We'll want to implement the guidelines laid out in this comment: #195048 (comment)

[Samiul-TheSoccerFan]

@daveyholler @mdefazio: Can you please confirm if this is what is expected considering all fields are required?