WCAG 3.3.1 fulfilled with disabled submit button?

[JAWS-test]

Many pages automatically validate form field entries and deactivate the submit button as long as, for example, not all required fields are filled in - and do not display an error message. Is this ok or a violation of 3.3.1, because no error message is displayed in text form and also no error message can be displayed because the form cannot be submitted. Or would it only be ok in case of required fields, but not for other errors?

Related: #922

[patrickhlauke]

This is an odd one for sure, because logically, this scenario doesn't fail 3.3.1 since no error has actually happened, since the user was simply prevented from submitting an erroneous/incomplete form. So purely from a 3.3.1 perspective, I think this is a pass/not applicable.

[JAWS-test]

since no error has actually happened

This cannot be said so simply. A form with required fields can also be seen as initial always as faulty. And an error validation takes place: It is constantly checked whether the submit button must be activated or deactivated. An error message is displayed, but unfortunately not in text form, but only graphically (greyed button) and in source code (disabled)

[gradualclearing]

From the understanding document:

The intent of this Success Criterion is to ensure that users are aware that an error has occurred and can determine what is wrong.

It seems that this pattern falls under the intent since an error is “automatically detected” and indicated using a disabled Submit button, which admittedly isn't a clear way to identify and describe the error. It's one of the error flows/patterns we've been exploring in the Errors Subgroup so I'm glad it's come up here!

[patrickhlauke]

A form with required fields can also be seen as initial always as faulty

taking this to the extreme, you'd require every form that has any kind of validation to show errors all the time, in text, until the user has filled it in fully. on load, showing errors in text for all fields even though the user hasn't even started filling it in. slippery slope...

[JAWS-test]

taking this to the extreme, you'd require every form that has any kind of validation to show errors all the time, in text, until the user has filled it in fully.

This is a misunderstanding. If the submit button is not disabled, I can click on it and get the error messages. This is about validation before submitting and I have no chance to get error messages

[awkawk]

If I have a form that takes my name in one field and requires a well-formed email address in another, and has a button to submit that is disabled until the form is ready to be submitted, I think that it is fine if the only indication that the email field is empty is that the submit button is inactive, but if I type me@mycompanycom into the form the error in the field data would need to be described in text.

[JAWS-test]

I think that it is fine if the only indication that the email field is empty is that the submit button is inactive

@awkawk: But this probably only applies if the required fields are marked as such and the number of fields is small (in your example only 2), right?

[gradualclearing]

I think that it is fine if the only indication that the email field is empty is that the submit button is inactive, but if I type me@mycompanycom into the form the error in the field data would need to be described in text.

@awkawk Can you explain your rationale? We're working through this error flow and looking to get different perspectives.

[bruce-usab]

My expectation would be that anything entered into both fields would cause the submit button to go from inactive to active. (I am assuming that there is accessible instruction that both fields are required.)

But, in my opinion (and I am guessing this is what @awkawk is thinking too) the additional requirement that the second field is a well-formed email address needs more of a cue than mere the submit button going from inactive to active.

So hitting submit with the email of me@mycompanycom (instead of me@mycompany dot com) needs to generate an accessible -- and explicit -- error message.

[patrickhlauke]

So hitting submit with the email of me@mycompanycom (instead of me@mycompany dot com) needs to generate an accessible -- and explicit -- error message.

but the crux of the problem is that you can't hit submit, because it's disabled. Arguably though, an error should pop up once the field loses focus perhaps. But is that required? I think that's the current gray area here.

[mraccess77]

It'd say that the email format error would need to be surfaced visually and accessible associated if the submit button remains disabled. Just one more reason why disabled buttons are a anti-pattern.

[bruce-usab]

I admit that it is a little hand-waving, but I am okay with submit buttons being disable if no entry is been made for any required field. It is a very common usage pattern, and I would argue that it good for usability (including for PWD).

On the other hand, I have been personally frustrated with long forms and many required fields (mixed in with many non-required fields) and the lack of an explicit error message. But I suspect those forms were failing 3.3.1, so probably not a good example.

If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.

Any non-trivial input detection would be covered by this, and the email addy not being well-formed is clearly an error that needs to be described to the user in text.

It also seems to me that this is similar how we allow simple search functionality to be passed without an explicit submit button.

[awkawk]

@JAWS-test I don't think that the number of fields matters for conformance. For usability, it would.

@gradualclearing Assuming that the field indicates that it is required, then an empty field that is marked as required provides the information that the user needs to fix it. But if the field is not empty and there is an error, additional detail is needed.