[A11Y] Suggestions for Button component when passing `disabled` property

[ibftcorp]

This is a recommendation to make the Button more inclusive to all users. The reference for this is across other website, but basically, I will highlight this part of A11Y-101.com:

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.

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

What is the issue?

• As a screen user, I cannot access a button using the keyboard/navigate to this button if the disabled property is there.
• Users should always be able to press/click on things, and we can send feedback after the press/click. In a signup example, you could present error messages.

How can we fix?

• We can add a javascript the aria-disabled property to the button, but this alone will cause a few problems, especially if you expect that developers will remember that to make an accessible button, you need to pass aria-disabled instead of the intuitite disabled attribute.
• Ideal scenario: You create a stimulus integration and when the developer pass the disabled attribute, you ignore internally in the component, and add aria-disabled instead;
• With stimulus do a simply check if disabled was passed, you cancel the submit/click event propagation with event.preventDefault();

This example is in react, but it's easy to see that is simple javascript: https://github.com/Automattic/vip-design-system/blob/trunk/src/system/Button/Button.tsx#L32-L43

[cirdes]

@ibftcorp, I understand your arguments, but I’m not sure we should go this way. I don’t like the idea of creating a JS script that removes the disabled attribute and adds aria-disabled instead, as this might not be expected or understood by the user.

I think we should keep the button as simple as possible for now. The user should use aria-disabled instead of disabled, understanding what they are doing to avoid confusion.

[djalmaaraujo]

@cirdes The proposed solution is not adding a Javascript code to remove a disabled property. Users writing code with the component would still use the disabled param, but instead of writing disabled in the HTML, you would write aria-disabled. When the user clicks on the button, you could have a e.preventDefault() if the disabled para was used.

The main idea is that disabling an element with the disabled HTML prop removes it from the screen reader DOM, making it inaccessible. You cannot TAB or get to this element using focus.

The issue created by @ibftcorp proposes the idea of inclusive components. The solution proposed is solid and accessible.

If the user you are referring is the developer of the final user? If the latter, they will have benefits, not doubts.

If the user you are talking about is the developer, this is a way to build more inclusive applications, and this won't change any behavior of the disable button. The final user will still get a disabled button at the end.

If you expect developers to remember to add aria-disabled, that won't happen. Accessibility is not for developers to feel good about what they are coding; it's for building inclusive applications.

Knowing that accessible code is not provided by the browser by default for all components implies that we will have to do it ourselves.

"The World Health Organization (WHO) has identified over 1 billion disabled people in the world. This corresponds to approx. 15% of the world’s population!"
https://www.adnovum.com/blog/accessibility-in-numbers.

[sethhorsley]

This sounds interesting if you can do it without adding JS. If you could open a PR we would love to check it out!