Steps to reproduce: 1. data:text/html,<input type="email"><button>go</button> 2. Use accerciser or a similar tool to monitor for state changes 3. Type "foo" in the input and press Tab, causing the input to be marked in red Expected results: A state-changed:invalid-entry event would be emitted so that a screen reader to present the error condition Actual results: There is no state-changed:invalid-entry emitted.

Hello, It seems this issue also affects Windows, I'm testing Firefox 60 with latest stable NVDA and when I follow the steps I don't hear invalid entry after leaving the input field. @Marco: Do you observe the same result as I've? Best regards, Alex.

No, I cannot reproduce. When I start typing, and just type the first letter, the screen reader automatically announces the "invalid" state. The only thing it does not announce is when that state is cleared, probably because the screen reader needs to have special wording for it. But NVDA's virtual buffer reflects that if I just clear the field and press Escape to go to virtual mode. It has the correct state cached, which means it received an event to the effect that the field is no longer invalid.

We indeed get a state-changed:invalid-entry event when typing the first letter, and another one once a proper mail address is typed. But that behavior is incoherent with the visual rendering in firefox: the red frame around the text field appears only when tabbing to the button, not as soon as when typing the first letter. That makes sense since the user does of course know that a one-letter mail address is invalid. It's only when she apparently thinks that she is finished with typing (she pressed tab) that it is useful to signal the invalidity. The same reasoning holds for screen readers: it would be better to report state-changed:invalid-entry exactly like the firefox visual rendering. Of course the screen reader could check the invalid-entry state when the focus leaves a text field, but that's reimplementing the firefox behavior in the screen reader instead of firefox just keeping behaviors coherent.

(In reply to Samuel Thibault from comment #3) > We indeed get a state-changed:invalid-entry event when typing the first > letter, and another one once a proper mail address is typed. > > But that behavior is incoherent with the visual rendering in firefox: the > red frame around the text field appears only when tabbing to the button, not > as soon as when typing the first letter. That makes sense since the user > does of course know that a one-letter mail address is invalid. It's only > when she apparently thinks that she is finished with typing (she pressed > tab) that it is useful to signal the invalidity. > > The same reasoning holds for screen readers: it would be better to report > state-changed:invalid-entry exactly like the firefox visual rendering. > > Of course the screen reader could check the invalid-entry state when the > focus leaves a text field, but that's reimplementing the firefox behavior in > the screen reader instead of firefox just keeping behaviors coherent. @James: As described above by Samuel the current implementation even on Windows seems different between visual feedback and accessibility feedback. I assume as Samuel there is a mistake not only on the GNU/Linux implementation. Are you OK to move the bug outside of Linux-specific to let it in your scope? Best regards, Alex.

Interestingly, I was literally discussing this with a user only a couple of days ago. Users find it confusing when they hear "invalid" before they've even finished typing. I suspected that this was only visually indicated after focus moved, and comment 4 confirms this. So, yes, I agree this is a cross-platform bug. That said, I have two thoughts: 1. I don't know how this works in DOM, but it's possible the change is signalled after the next control is focused. If so, the state change might get fired after the focus event for the next control. Event coalescence might cause a similar issue. For screen readers, this would be bad because they probably wouldn't report the change, since the associated control isn't focused any more. 2. Even if we don't fire the state change immediately, does it still make sense to expose the invalid state? I guess not, since it's not indicated visually. Note that I have no idea how we'd implement this, since it seems the notification we get is different to whatever is done for visual indication.