Read-only state for buttons? about html HOT 6 OPEN

is marking a button as read only going to actually solve anything though?

messaging as to why the button doesn't do what the user wants/expects would still need to be provided. being read only wouldn't solve that. Arguably what could be done now is not assigning an event to the button / preventing default until whatever condition is met - and still provide the necessary messaging / alternate behavior to render that messaging.

from html.

What does "read-only" mean for a button, and how is it different from the existing disabled state? Buttons are not typically thought of as "writable" in the first place.

from html.

What I am seeing is an increasing number of teams putting information on disabled buttons via hover -- explanations of why it cannot be clicked right now, or how to resolve the disabled state.

This sounds like an anti-pattern. For one, hover states are not always discoverable:

• how do you show, that there is information to resolve the situation on the button?
• what happens on touch interfaces?
• is this information available elsewhere in the vicinity of the button?
  And for another, how does a read-only button (in my mind a button is always read-only, as a you can only interact, not write to it) solve for this?

and as @lbeaze said:

But, designers and developers would still have the work of telling people why it's not a fully functioning button, right?
→ Which will be happily ignored by 99% of authors.

from html.

keep it enabled, but instead of doing its intended action, it opens an explanatory overlay

Having a UI react to input, even with an error, is nearly always a better experience for users than not responding at all

from html.

I guess I'd say 'navigable but not actionable'.
What I am seeing is an increasing number of teams putting information on disabled buttons via hover -- explanations of why it cannot be clicked right now, or how to resolve the disabled state.
When you think about it, it's an obvious thing a user who encounters or tries to activate a disabled button asks themselves: why is this button disabled?

So it's a natural development that designers should start to seek ways of surfacing information about the interaction to the user.

The problem is that disabled buttons should not react to hover, and even if they did, they are not in the keyboard order, and so information on hover is withheld from users reliant on keyboard.

I've seen teams try things like altering the button's function (i.e., keep it enabled, but instead of doing its intended action, it opens an explanatory overlay; sometimes they'll try changing the button's label). Others have explored putting text near the button explaining why it can't be used. Neither are particularly optimal.

from html.

I can see the natural progression from a disabled button - and the value of AT discoverability of these types of buttons.

But, designers and developers would still have the work of telling people why it's not a fully functioning button, right?

Or are we coming up with a solve for the remaining issues?

from html.