[SCREENREADER]: Inline error messages are announcing to screen readers on correction, not on subsequent errors

[1Copenut]

Audit Information

• Date: September 17, 2018
• OS: Windows 7 64 bit Enterprise, Service Pack 1
• Browser: Internet Explorer 11
• Screen Reader: JAWS 2018

Describe the bug
Form inputs have inline error messages that are designed to announce themselves to screen readers when an input is invalid or empty. The error messages are firing correctly when inputs are blurred, but are announcing when users re-focus the input and provide a valid entry. The inputs are also not announcing the error message when users provide a second invalid entry.

To Reproduce

1. Go to any form input, especially a standard input[type="text"] which is where the behavior was noted
2. Focus, and blur the input, preferably using TAB or arrow keys
3. Verify the error message announces itself
4. Refocus the input
5. Verify the error message is not read aloud
6. Key in a valid entry
7. Verify the error message is read aloud, even though a valid entry was provided
8. Key in an invalid entry a second time
9. Blur and re-focus the input
10. Key in a second invalid entry
11. Verify the error message is not read aloud, even though the input was in error

Expected behavior
The error message should be announced to screen readers when an input is blurred with invalid or empty data. The error message should fire a second time when invalid data is entered a second time, but should not announce when users enter valid data to correct the first error.

Screenshots

---

[dmethvin-gov]

Just noting here that we don't seem to use a lot of aria- properties and neither does react-jsonschema-form. @1Copenut is it clear which input has the error when it is invalid? Should we be setting aria-invalid on the input or associating the error message somehow with the input?

[1Copenut]

@dmethvin-gov I've been thinking about the aria-invalid attribute and will have a more complete understanding with test research, on Monday.

[rroueche]

@1Copenut decision from our meeting with Chris J, James K, Alex T: let's fix this the right way, even though it's a significant lift, and solve through the forms library. Can you please make sure there's an issue in the Team Repo for this, in the Ready column w/a brand consolidation label, w/a description of the solution, and an estimate of the risk/complexity/difficulty? Ping me (Rachael Roueche) in Slack when done so that Chris and I can move this issue up in our list of work to tackle!

[1Copenut]

@dmethvin-gov I have been experimenting with a few options and have asked the team I work with for assistance. I will follow up here when a best option has been settled on. Thank you for the opportunity to contribute.

[dmethvin-gov]

From what I can gather from "teh internez" we need to set aria-invalid on the actual input and use aria-live=true for the error div. However we may also need to leave more of the (empty) error content in place so that the screen reader understands the content in the (existing formerly empty) error content has changed and will speak it. Note that this is inside react-jsonschema-form.

[jbalboni]

Adding aria-invalid is straightforward enough. The sticking point here looks mainly like re-announcing an error when you blur an input. Our errors already use an alert role and get announced when that text changes, but if that error text doesn't change (like if you blur an input without fixing it), then it doesn't get read again. I'm not sure how we could force that div to be cleared and re-populated to trigger the error being read, in the React component tree.

[1Copenut]

Yes, the main sticking point is JAWS + IE11 reading the error message twice. In the current scenario, if an onBlur event fires and a field is invalid, the error message is read out immediately. Where it becomes a problem for JAWS is when users re-focus the input and enter correct data. When the next onBlur event is fired, the error message is read out again, even though we're removing it as part of the interaction.

I did some testing on a local mockup to see if I could re-create the issue, and I was able to do so. If the error message is removed when the input received focus, JAWS reads the error message immediately, then re-reads the input label. IMO, this is a preferable situation to reading the error message a second time after users have typed in potentially accurate information.

If there's a preferred way to share code samples (Codepen, Code Sandbox) I'll drop my findings there and update this comment with a link.

[dmethvin-gov]

Removing the error message on focus is going to be confusing for sighted users, especially if we set focus to the first field with an error. They will end up in the invalid field without a visual description of the error.

Would it work to clear the error on the first change (generally, an input keystroke) to the field after it's been focused? That would be the HTML "input" event which corresponds to the React "onChange" event.

[jbalboni]

I'm a little confused about how JAWS is reading an error message when you enter a valid entry. The error message is removed as soon as valid data is entered, so it shouldn't exist for JAWS to read. Is it a timing thing, in that JAWS is reading out the error message and it isn't interrupted if the user fixes the data before it finishes?

I can't reproduce that issue in VoiceOver, so it's hard for me to test out solutions.

[1Copenut]

JAWS and IE11 is keying on the <span role="alert">...</span> being removed from the DOM, and reading it out a second time, is my guess. I'm not versed enough in how IE11 is interpreting the DOM to say for sure, but I am able to recreate the problem locally, and happy to screen share or video chat anytime.

Removing the error on first change seems a good balance for sighted and assistive device users. I'm going to modify my local test because I'm curious how JAWS handles it, and will report back when I have a better understanding.