Set aria-disabled instead of disabled on Button / SubmitButton

[chawes13]

Disabling a button can be confusing for users as it generally doesn't provide information as to why it is disabled. Additionally, it removes the button from the tab order so users of assistive technologies may miss it altogether, depending on their style of navigation and the implementation of the AT.

Instead of setting disabled, we could set aria-disabled="true", which would allow the button to be focused and would alert screen readers that it was disabled. Styling could target this attribute instead of disabled. Additionally, we could force a noop when invalid is true OR we could force developers to handle the errors and tell users why the form failed.

References:

• https://haltersweb.github.io/Accessibility/submit-disabling.html
• http://form.guide/best-practices/form-validations-definitive-guide.html
• https://axesslab.com/disabled-buttons-suck/

[dpikt]

I'm down with this. In generally, we disable buttons much more often then we have to- potentially we could fix this issue simply in the way we render these buttons.

For instance, right now we often write:
<SubmitButton {...{ pristine, invalid, submitting }}
which disables the button when the form is pristine or invalid.
But by writing:
<SubmitButton {...{ submitting }}
we would avoid the disabling behavior. This has the advantage of allowing the form to submit, which shows sync errors. Also, disabling the form when pristine doesn't seem to have much upside to me- at best, we avoid an extraneous API call but the UX is kinda confusing.

[dpikt]

What do you think about making this change to usage? Any potential downsides you see?

[chawes13]

I definitely agree with your comment about the pristine disabling behavior. I like the idea of changing this usage, but I could see a downside in terms of enforcing it without updating the component.

I'm in favor of removing the behavior to set disabled based on these props, instead forcing a developer to set disabled manually when they truly want to disable something. However, this would likely be considered a "breaking change".

[dpikt]

Yeah that's most definitely a breaking change. I feel like I could go either way on it. The behavior is arcane enough that if we removed it from any boilerplate (form component snippet) it probably wouldn't persist in any new apps moving forward. I guess the question is whether we want to retrofit our old apps- but that could also occur without a library change.

If we go for it, we should make sure to get any important minor upgrades in before it as well.

[chawes13]

Can we mark this as a topic for discussion at the next priority meeting?

[dpikt]

@chawes13 sounds good!