This demo is currently a work in progress.
First, I'd like you to consider whether or not you need to disable your buttons. Buttons that submit forms are often disabled until the form values are all valid. This pattern may be easy for non-disabled mouse users to follow, but for folks with vision, cognitive, or phsyical disabilities, for example, this pattern can lead to a lot of confusion and frustration.
You're probably used to disabling buttons by adding the disabled property to them. This isn't inherently wrong, but it isn't the best way to handle disabling buttons. When the disabled property is added to a button, it is removed from the tab sequence of the page. This effectively hides the element from people who would normally tab through content, such as a form, while using a screen reader.
This is where the aria-disabled property comes in. This property, like all other ARIA attributes, does not change the functionality of the button. All it does is tell screen reader technology that it needs to be presented in a different way than usual. A button with the aria-disabled property set is fully perceivable, unlike a button with the disabled property.
Let's quickly get back to whether or not buttons should be disabled in the sense that they are not operable. What the answer comes down to is valuable user feedback. If a button is disabled:
Even if you answered "Yes" for all of these questions, your interface will be more informative if you allow the user to always activate a button and then provide feedback them immediate feedback if something is wrong. For example: If the button submits a form that is not valid, show a descriptive error message when the button is activated. This can be done with live regions and one is used with the second button in the demo below.