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.

[cstrobbe]

Patrick Lauke:

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.

JAWS-test:

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)

I wouldn't argue that "a form with required fields can also be seen as initial always as faulty."

There is a different way of looking at it: the submit button remaining disabled after the user has tabbed through all the fields is an implicit indicator that an error has been detected. (Note that I did not write "the submit button being disabled" or "before interaction with the form".) If no text-based error messages are displayed, the disabled button is the only way of indicating that there is an error.

Screen reader users and other keyboard users who continue tabbing after the last form field may land somewhere outside the form, possibly much lower on the same page, because the disabled button does not receive keyboard focus. This is confusing, since it is not obvious what exactly is wrong. (Keyboard users who use magnification may not see the empty required field when they are at the end of the form.)

Andrew Kirkpatrick:

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 (...)

That gives keyboard users a user experience that is much worse than that of other users. If users with disabilities are disadvantaged in comparison with other users, I'm not sure this is "fine".

Bruce Bailey:

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.

I think the question is: if an incorrectly formatted e-mail address has been entered, is the Submit button remaining disabled a failure of SC 3.3.1. Since keeping the disabled state can be seen as an implicit error indicator that is not in text, it can be argued that this is a failure.

[mraccess77]

I take the stance that if the submit button is grayed out until you complete a field correctly that is communicating an error has occurred. If we don't require suggestions or error identification in that case (when detectable) then the intent of the SC is not met as once you get all of the info right the submit button becomes ungrayed and there is no error to display as the data is correct.

[cstrobbe]

I take the stance that if the submit button is grayed out until you complete a field correctly that is communicating an error has occurred.

If the button is greyed out before the user has started interacting with the form, claiming that an error has occurred does not make much sense from a user's perspective. Note that the SC says, "If an input error is automatically detected". How can an input error be detected before any input has taken place?

[patrickhlauke]

How can an input error be detected before any input has taken place?

i could imagine a reasoning along the lines of: the scripting has automatically detected that the form is in an error state (e.g. you haven't filled everything in, or you made some mistake), and disabled the submit button in response.

[cstrobbe]

i could imagine a reasoning along the lines of: the scripting has automatically detected that the form is in an error state (e.g. you haven't filled everything in, or you made some mistake), and disabled the submit button in response.

If this reasoning were intended by the SC (which I doubt), wouldn't at least every required field need an error message pointing out that the field is required, even before the user begins interacting with the field? (After all, we aren't talking about labels here, which may also mark a field as required.)

[mraccess77]

The SC is about fields that can be automatically detected in error. If the form is disabling a button since you don't have all of the data entered then it is very much automatically detecting this and disabling the button. I agree with AWK Indicating required fields by the fields that are required would solve this.

[ChrisXKeroack]

Decent accessible error handling, and a form with an always available submit button, is always preferable to me.

Unless the form has clear instructions at its start, I'd argue that forms that use disabled submit buttons with no other visual instruction should fail 3.3.2, since the user can't get clear instructions on how to use the form.

1. The instructions are never explicitly stated, they're inferred by the submit button's state and behavior.
2. Not sure how we can have all this work done recently in WCAG towards cognitive issues yet support a design pattern that communicates essential information primarily by inference. The same user who needs direct, clear, consistent instructions in other circumstances, likely needs more direct instruction here too.
3. The fact that the submit button is disabled can be easily missed by screen reader users or by keyboard users at high magnification, as @cstrobbe mentioned previously. So even if point 1 is okay here, those users won't get the inferred 'instruction'.
4. Much of the discussion on this subject, like the discussion in here, is semantically / logically correct in the context of interpretation of WCAG but not necessarily intuitive to the average user. It's a lot of "inside baseball" for people who work on this all day every day. I think the expert user is assumed or over-represented here, and I am not certain that the average user is necessarily going to go through the same thought process or notice the same things as we are in this discussion.

So, in other words, if the disabled submit button behavior is on a form, then that form needs to have all required fields visually and programmatically marked as such, and the form needs instruction at the start of the form that says e.g., "all required fields (marked with *) must be filled out in order to submit the form". That makes the submit button behavior more a UI reinforcement of provided instructions, and not the sole/primary instruction.

[patrickhlauke]

that form needs to have all required fields visually and programmatically marked as such, and the form needs instruction at the start of the form that says e.g., "all required fields (marked with *) must be filled out in order to submit the form

so, even on a basic login form with username/password? that sounds excessively harsh as a failure, sorry

[ChrisXKeroack]

Disabling the submit button until both fields in a two-field login form are filled out seems odd. Is that really common now?

[patrickhlauke]

irrelevant whether common or not. you either say something MUST be done all the time, or not. can't make a pass/fail depend on "how common is this?"

[ChrisXKeroack]

Very reasonable point. In that case it’s a fail even for a lowly 2-field login form.

[patrickhlauke]

[edited above comments to remove email reply noise]

that is far arguably a too harsh/pedantic interpretation of the SC... some related previous discussions where we've been around this particular bend before #1698 and #2357

[ChrisXKeroack]

some related previous discussions where we've been around this particular bend before #1698 and #2357

Thanks for those pointers, that's excellent; will go read up on those.

[awkawk]

I wouldn't apply 3.3.1 to the situation. 3.3.1 applies when an input error is identified, and since input error is defined as "information provided by the user that is not accepted" - if the user hasn't entered anything then there isn't an input error.

[mraccess77]

@awkawk that doesn't seem different than a user not entering anything into a form field and submitting and needing to get an error message saying that some information is required.

[awkawk]

Yes, but it isn't an error until the user tries to submit the form and of course the user can't submit the form if the submit button is disabled. I don't think that it is a good user experience, but I can't reconcile it as a 3.3.1 error either.

[fstrr]

This issue is labelled as a discussion, so we’re moving this to Discussions. There doesn’t seem to be an update to make to the documentation, but if that changes, we can move it back to the issues list.