aria-invalid cleanup

[Garry Yao]

With JAWS opened:

1. Open link dialog;
2. Without putting anything in the URL field to trigger the invalid error;
3. Fill in the URL field, tab to the dialog buttons and shift-tab back to the input.
4. Ask JAWS to announce the field;

• Actual Result: JAWS read it as invalid text input.

[Garry Yao]

Wouldn't it better to have the re-validate happens upon field blurs? I'm confused as I saw ​some other implementation act the same way as with us right now.

[Frederico Caldeira Knabben]

I understand the reasoning behind our current behavior and the example you've linked. The idea is that the field enter an "invalid state" *upon validation*. Such validation happens with a specific action, which is the "Ok" button in our case (alla form post).

Doing validation on blur is a bit of a pain in the ass. Firstly, it's easy to avoid the validation, by just clicking on a field after the validated one. Other than that, the user may want to work on the fields on a different order, and it sucks when you have alerts saying that you need to fill fields that you planned to fill later.

We may do an usability enhancement for accessibility anyway, based on the "on blur" idea:

• Revalidate on blur only if the field is already invalid.
• If it's still invalid, nothing happens and no error messages are thrown.
• If it's valid, the ARIA related validation stuff is removed from the field.
• The full validation will still happen on "Ok", just like now.

There is no hush on this though, as our behavior is jus tnormal, even if still not optimal.

[Mike Gifford]

Would be good to see this is fixed in the 4.x branch though. It may not have been a rush 2 years ago, but I'd like to see this issue closed (and fixed).