[Proposal] Error message patterns and behavior for screen reader UX

[1Copenut]

Description

EUI has two UI patterns for validating form errors. I'd like to discuss these patterns more closely. My goal is to get consensus on how we can adopt these patterns to fit potentially three user flows.

The first UI pattern is to include a callout at the top of an EuiForm component. This callout receives keyboard focus on the submit event and has a role="alert" attached to it. Screen readers announce chime an alert message and read the callout errors immediately.

The second UI pattern involves adding an EuiFormErrorText to EuiFormRow. This error message also includes a live region attribute, so screen readers try to announce individual error messages when they appear on the screen.

Succinctly, this is the problem. We need screen readers to announce errors reliably so users can correct them, without being too distracting or repetitive. I see three possible patterns for how we handle errors. I'm not prescribing use cases to these (yet), just outlining the patterns I propose:

User flow 1: Callout with descriptive error messages on form submit

We would use the existing EuiForm callout to announce errors to users. The callout box would receive keyboard focus on the form submit event. Users would hear the callout title, then could traverse through the individual error messages (they're an unordered list),. Ideally these errors include the input name and are very descriptive why the input is in error. Ex. credit card number must be 15 or 16 digits.

In user flow one, we would opt not to use the EuiFormErrorText on individual inputs, just the red border, red icon, and red text. We should associate the error message with the input by using aria-describedby. This way we retain the semantic relationship between input and error for all users.

User flow 2: Callout plus individual error messages on form submit

The third flow would use the EuiForm callout and EuiFormErrorText to announce errors on form submit. This pattern is similar to pattern one, but the callout can be more general (number of errors, etc) while the individual error messages are more descriptive. We would still alert screen readers and set focus on the callout box.

User flow 3: Individual errors only on form submit

The third flow would use the EuiFormErrorText only, no callout box. This pattern is potentially more noisy than 1 or 2, but offers immediate feedback to users. Inputs would all be validated at the same time. We would need to test multiple screen readers for how multiple role="alert" messages get announced (some stack these, others only announce the first, etc.) and we would need to set keyboard focus. My hunch is we would set focus to the first input in error in this case. Quick user testing should validate the efficacy of that statement.

User flow 4: Individual errors only on input blur

The fourth flow would use the EuiFormErrorText only, no callout box. This pattern is also potentially more noisy than 1 or 2. Each input would self-validate when the blur event fired, and errors would be appended immediately. Each error would have a role="alert" so screen readers would announce them immediately. We would not need to worry as much about errors stacking up unless errors were programmed to treat empty fields as invalid. We would also not need to worry about focus management because users have not taken a terminal action like submitting the form.

Additional resources

https://eui.elastic.co/#/forms/form-validation

---

WCAG SC 3.3.4: Error Prevention (Legal, Financial, Data)

For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true:

• Reversible
  Submissions are reversible.
• Checked
  Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
• Confirmed
  A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.

https://www.w3.org/WAI/WCAG21/Understanding/error-prevention-legal-financial-data.html