Read-only state for buttons?

[mbgower]

What is the issue with the HTML Standard?

We're seeing more cases where teams want to provide a button with a recognizable read-only state.
Here are the outcomes desired:

1. Low vision users are able to see what the button's function is, since they can read the label with decent contrast.
2. Sighted users can understand the button is not currently available based on a recognizable visual indicator that it is in a read only state
3. Screen reader users can more easily discover the button during familiarization with a page, especially in forms mode, since it takes focus.
4. Screen readers (and other AT users) can learn the button's read-only state.
5. All users can potentially discover some context for why the primary function is not available, either via information exposed on hover/focus.

At the moment, we have not discovered a consistent way to achieve those 4 objectives. We'd appreciate any thoughts on either 1) why it's important that there should not be a discernible read-only state for a button, or 2) other recommendations you have for dealing with the above desired outcomes.

[domenic]

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.

[mbgower]

What does "read-only" mean for a button

I guess I'd say it means '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 asks themselves, who encounters or tries to activate a disabled button: 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.

[joelanman]

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

[lbeaze]

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?

[scottaohara]

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.

[othersmallcities]

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.

[mbgower]

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

Cleary, the response has been that no one likes the notion of a read-only button. Understood. But I'd like to focus on the "solve" part of this response.

Looking at the github issue interaction, the comment button is disabled until such time as I not only put focus in the Add a comment field, but until I actually add some text to it. (It is visually discernible for those who can see it, providing a promise of the potential to comment.)

I'm assuming we can all agree that disabling buttons is a common method for ensuring people don't try to activate them when they are not yet valid.

Can we also agree that putting hover information on a disabled button is not allowed?

That will at least let me push back against teams doing it.

I suspect this is not the best forum for discussing "other recommendations you have for dealing with the above desired outcomes." So, once I get the confirmation that disabled buttons cannot respond to hover, this can be closed.

[aardrian]

I'm assuming we can all agree that disabling buttons is a common method for ensuring people don't try to activate them when they are not yet valid.

It is one method, yes. It may be common for some sites and users, but there are still plenty of places that don't do it (and rely on error messages and/or preventDefault and/or other methods).

Can we also agree that putting hover information on a disabled button is not allowed?

If by "not allowed" you mean WCAG has an SC that says how not to do hover content on anything as well as another one saying it must be keyboard triggerable, sure?

That will at least let me push back against teams doing it.

Ah, then SC 2.1.1.

[mbgower]

If by "not allowed" you mean WCAG has an SC that says how not to do hover content on anything as well as another one saying it must be keyboard triggerable, sure?

I was hoping there was something saying disabled buttons are inert, but on discussion, realize that is not the case -- a title attribute on a disabled button can be revealed by hover. Another example of inequitable interaction between pointers and keyboard.

I don't believe what I'm describing would fail 1.4.13 , but yes, I will revert to failing it against 2.1.1.

Thanks.

[mbgower]

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.

When I just referred another person to this issue and its response/result, I realized I never responded to @scottaohara's question.

If you go back and look at my list of problems in the original issue, I would say 'yes' it addresses a number of those issues:

1. As a non-disabled component, its label is going to have to meet contrast minimums and therefore be more perceivable for low vision users.

2. No one in this thread has discussed how to make something distinguishably read-only, so this is obviously a design challenge and needs a solution (as it does for all components that can be in a read-only state; we had to develop a whole visual treatment for read-only in Carbon).

3. and 4. If a read-only button remains in the tab order and its state is exposed, that obviously improves discoverability for blind users. If it can take focus, then any title messaging can be displayed on focus, which benefits every user not operating by mouse.

4. (number 5, really; can't be bothered overriding this auto-numbering). I hope it's obvious that a read-only state could in several ways make for a more equitable experience for a button that is present but unavailable.

[aardrian]

None of those items (especially item 2) seems to be something that can only be solved by making a button read-only.

So to item 5, it is not obvious to me how this would make for a more equitable experience unless you think making a button disabled is the only other option available (versus messaging and not submitting until conditions are met).

[mbgower]

To be clear, @aardrian , I'm not saying making buttons read-only is the only solution. I was responding to @scottaohara's question about whether a read-only button would solve any of the desired outcomes.

I also want to emphasize that I'm not actively advocating read-only buttons with teams. Quite the opposite. What's occurring is I am frequently assailed with teams telling me they want to do it. Here's the latest example that precipitated me posting something else to this closed issue.

Another discussion we could maybe consider breaking open is there's been some thinking that inputs that are disabled should still be focusable so screen reader user can still identify the existence of those items and so you don't have to give them whiplash when something becomes disabled and loses focus. That kinda violates all the rules of the past but I've seen efforts to actually change this. It can be done without browser support and I think [some] have started adding an option for doing that on their stuff.

The user said "input" here, and I'm following up to understand the entire interaction. One I've seen, which might be getting referred to here, is to do with user feedback on AI-generated responses in a chat. It's something that is getting traction as a fairly common interaction to improve transparency and provide agency. There are obvious considerations: 1) the thumbs up/down icons add more time on task for keyboard users; 2) once a user has submitted feedback on that piece of generated content, the business rule is they cannot alter the feedback. So, if the thumb buttons become disabled, a sighted user can see they've become unavailable (and also see he/she activated one) but for a screen reader user, the buttons are removed from the interaction.

Again, I emphasize that I understand there are other ways of tackling this problem, right back to whether a bunch of thumbs in a chat UI is the most elegant way to allow user feedback on AI.

[aardrian]

Gotcha. Thanks for the added context.