VA Forms System Core [Discussion]: Global - How should multiple errors be handled and when should errors be triggered?

[TiffanyPender]

Issue description

Currently, the form errors get announced with role="alert", however, there are some ways the experience could be improved.

1. The errors are vague. They all say something like "Please provide a response". This could be because this is a demo form, and if that's the case, no problem. However, if this is a default setting for the components, we should rethink that. Let teams define that on their own using our content guidelines. Moved to ticket #586
2. ~~When do we trigger errors? Currently, errors get triggered if a field is blank. While this makes sense conceptually because veterans can't submit blank data on required fields, it creates challenges for people who use assistive technology. People who use screen readers may often quickly tab through the fields without filling them in to understand what's on a page. When errors get triggered during that process, it becomes overwhelming. How might we design to respect that way of scanning a page? Some ideas: a. Trigger errors on "Continue" button press. b. Only trigger errors after a person leaves a field if data is in it. In other words, only trigger errors on blank fields when "Continue" is pressed.~~ - Moved to ticket #588
3. ~~How should we handle multiple errors? Currently, the form doesn't make a distinction between one error on the page or multiple errors. Nothing happens when you press "Continue" or "Previous" and inline errors are present on the page. We could handle this better for an improved experience. Some ideas: a. Have an error summary component that summarizes errors on the page at the top if a page has multiple questions/fields. Shift focus there on button press. b. Shift focus to the top most error on button press.~~ - Moved to ticket #587

Environment

• macOS Monterey, <Version 12.4>
• Chrome, <Version 102.0.5005.61>
• VoiceOver
• Staging

Steps to Recreate

1. Visit the Forms Library Core demo form
2. Navigate through each step in the form with required fields
3. Verify the error handling experience

[obliviga]

Here is an error summary component from the UK government design system that we could potentially reference: https://design-system.service.gov.uk/components/error-summary/

[taylorkaren]

Notes from the discussion we had about this topic in the 8/11/22 Preliminary Findings meeting:

Error messages work functionally, but we can improve the experience when there are multiple errors on the page at a given time (how do we manage that for people?)

• Inline error messages appear visually, but no alert and no focus on the error message, Angela has the same form again, works down it and tries to figure out what happened.
• Suggestions:
  • Create Aria alerts so screen readers announce the message
  • Move focus to first error
  • Create a list of error messages at the top of the screen and put focus there (this is the best option).
  • Matt: Error messages at the top of the page is a pretty standard pattern we should be following.
  • Micah: This is a shift from how error messages are currently handled, potential for the same sort of research and redesign approach as we did with the review page. Think the current pattern is to focus on the first error message on the page, not a list at the top of the page, as there is no error list right now.
  • Matt: This is a bug, this is the most common way to handle this, we should make this change.
• Second error message issue occurs when tabbing past a required field with no entry: you get an alert when you go back and the field you leave can then potentially announce an error.
  • Solution: Make it so a string of characters must be in the field to trigger the error message (min 1-6 characters).
  • Micah: This makes sense to me.
  • Matt: Components may throw an error if they are blank - need to look a this.

[taylorkaren]

Notes taken in the 8/18/22 Accessibility audit issue review and discussion meeting:

• David Kennedy filed this as a discussion starter. This would be a very large change; what research (if any) do we have about how Veterans react to error messages (individual or multiple)? Any problems noticing or correcting errors? It's a usability issue for screen reader users, are there also problems for Veterans who are not using screen readers? It's important to look at the two issues noted above, although they are tightly coupled. May be simpler to separate working on them, if possible.
• Tiffany Pender: Will take some time to come to a consensus to decide how to handle this. Maybe start with better text explaining what the errors are, and couple that with some research.
• Anish Kshatriya: What if no one is confused or has problems when we do research? How would that affect this decision?
• David Kennedy: That's a really good question. Had this discussion on healthcare.gov, did not group error messages at the top. It was complicated, users never really had problems with error messages when doing user research, but none of the research participants were really using screen readers. We should focus our research on people with screen readers and see what the findings from that indicate. May also want to think about when error messages are triggered; e.g., if only when Next or Submit is selected, this could take away the frustration of just skimming through the fields with the screen reader and getting error messages. Summary of error messages at the top of the page may not be the best on short pages.

[taylorkaren]

Discussed this ticket with @humancompanion-usds during the 8/23/22 PO Sync call. Matt will add a comment to this ticket summarizing the way forward on this issue.

[humancompanion-usds]

A couple of thoughts here:

I agree with Tiffany that we should be able to "start with better text explaining what the errors are". Let's at least do that.

I still feel that summarizing the errors at the top is preferable to not doing that. We will need to do research to figure out if a complete summary is necessary or whether a count of errors or some briefer message is sufficient. We'll either look to find a VFS Team to try that out or get to it ourselves in the future.

I haven't had a chance yet to talk to the DST about what it would take to allow for tabbing through form fields without throwing errors. I believe we all agree that a minimum entry should be necessary before firing an alert. I just don't know technically across all of our form components how far we are from that behavior today (i.e. how many components we would we need to refactor). I believe we just did this for the new Memorable Date component so, it should be possible. I will file an issue for that for the DST to mull over.

[taylorkaren]

"start with better text explaining what the errors are" is now ticket #586. Research ticket for "summarizing the errors at the top" is now ticket #587.

tabbing through form fields without throwing errors" is now ticket #588.

[taylorkaren]

Split this ticket into three tickets (see comment above) for easier tracking. Will close this ticket as issues will now be tracked on the new tickets.