[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.

[dmethvin-gov]

@1Copenut is it just JAWS that does this, or do some of the others do it as well?

[1Copenut]

@dmethvin-gov It is just JAWS, when coupled with IE11. I haven't seen it with other browser + screenreader combinations.

I just hit on an experiment that might solve the issue, basically creating the error <span> on the blur event where needed, and appending it after the <label>. This solution will notify screen reader users of an error promptly, and doesn't read out the error a second time when user starts typing in an input and the error message is removed from the DOM.

It works in preliminary findings, but not quite ready for sharing. I'll post it up later today when I've had a chance to confirm it works on all browser + screen reader pairings.

[1Copenut]

@dmethvin-gov I had a chance to go back to the experiment I was working on, and might have something. It's on Codepen here: https://codepen.io/tpierce_402/pen/Lqezye

I discovered in testing that creating a <span> to hold the error message and adding and removing the role="alert" attribute would stop IE11 + JAWS from reading the error message a second time.

Visual users could have the same experience where the error doesn't drop out until they start typing. Aural users will hear Field name, invalid text entry. The error message will fire again when the field is blurred if the input is invalid or empty.

The code is just proof of concept, so I could test it as easily as possible. Let me know if it'd be better to fold it into a branch on the US-forms-system repo.

Tested on:

• Win10 + IE11 + JAWS
• Win10 + Chrome + JAWS
• Win10 + Firefox + NVDA
• MacOS Mojave + Safari + VoiceOver

[RickHawesUSDS]

Opps. Accidentially moved this into in progress. Sorry.