formik Change suggestion to disable form submission button in order to encourage more accessible approaches

📖 Documentation

The problem

Disabling the form submission button is generally considered to be bad for accessibility and that's why it's not uncommon to be guided against doing so.

When a button picks up the [disabled] attribute, focus shifts from the button to the document.

For screen reader users, this triggers an announcement. For people who use the keyboard to navigate (both screen reader users and sighted users), they’re now no longer in the field they were working in and might be disoriented.

https://gomakethings.com/dont-disable-buttons-while-submitting-forms-with-ajax/ (24.09.2020)

Relevant documentation

Formik's documentation for form submissions has a frequently asked questions section that covers guarding against double submission and it states the following:

Disable whatever is triggering submission if isSubmitting is true.

https://formik.org/docs/guides/form-submission

As far as I understand, this advice would often result in the developer disabling the submit button.

Suggestions for amending

The fix would be to replace this advice with some other advice. In other words, Formik should adopt some other approach that it promotes for guarding against double submission.

People with better visibility into Formik's internals can likely give a better answer. Often the usecase is that we do not want to send the same data to the API twice. Then the following could suffice (although it's not possible currently):

<Formik
  onSubmit={() => {
    if (!isSubmitting) {
      handleOnSubmit();
    }
  }}
>
  {formikProps => (
    <Form>
      {/* ..fields */}
      <button type="submit">Submit</button>
    </Form>
  )}
</Formik>

With this approach the form still goes through the submission steps and is for instance validated. Is that beneficial? At least if we look at the previous solution, disabling the button, then this approach is not on par. Instead we would want to avoid going into the submission procedure altogether:

<Formik onSubmit={handleOnSubmit}>
  {formikProps => (
    <Form
      onSubmit={
        formikProps.isSubmitting
          ? e => {
              e.preventDefault();
            }
          : formikProps.handleSubmit
      }
    >
      {/* ..fields */}
      <button type="submit">Submit</button>
    </Form>
  )}
</Formik>

The following approach takes advantage of the prop spreading in the Form component to override the onSubmit handler in order to ignore the submission when isSubmitting is true. This approach likely does what is needed (I haven't tested it), but I am not sure if it's simple enough to be something Formik would want to promote in its documentation.

I searched issues and found the following with some relevance

https://github.com/formium/formik/pull/904#issuecomment-420995609

Sep 24 '20 06:09 Jokinen

Thanks for the write up. This makes sense but might better handled in the core with a prop like submitMode: block | continuous. You def want the ability to turn it off in autosave scenarios. I will ping some a11y experts from Chrome team about what they think is right and report back.

Sep 24 '20 12:09 jaredpalmer

When a button picks up the [disabled] attribute, focus shifts from the button to the document.

Interesting. I never knew about this. The problem seems in fact much worse than this.

https://a11y-101.com/development/aria-disabled

Now close your eyes and imagine the screen reader reads out all the inputs of a form. You know you're within a form. And normally a form gets submitted by hitting a button. But our form depends on the fact that every input has to be filled out - or something else has to happen before it can be submitted. Thus we disable the button until all the conditions have been fulfilled. All sighted persons will get it. The button is semi-transparent. But when a screen reader doesn't ever reach the button, then he will never indicate that there's a button.

In this case we can use an aria-disabled="true" instead of the good old disabled.

Maybe we should switch to aria-disabled in documentation. This won't prevent users from clicking the button though. It seems to me like screen readers shouldn't skip disabled inputs. There is a word for that after all, hidden. Why do the screen readers have to fight us at every turn 😢.

I'd see what the a11y folks say, most of the information I found wasn't modern, or from recognizable authorities on the matter in my brief search. (I have never heard of a11y-101). We want to make sure this info isn't outdated.