Comments (9)
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.
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.
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.
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.
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.
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.
from html.
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.
from html.
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.
from html.
Related Issues (20)
- Meeting 2 for joint OpenUI-WHATWG/HTML-CSSWG task force on styleable form controls HOT 4
- Upcoming WHATNOT meeting on 5/23/2024 HOT 6
- [Proposal]: Enable `HTMLElement` attributes to be toggled without JavaScript HOT 2
- Issue with Step 10 of inner navigate event firing algorithm HOT 2
- Provide native validation messages for native validity states on Form Associated Custom Elements
- Upcoming WHATNOT meeting on 5/30/2024 HOT 2
- Feature Request: Top Layer Stack Management HOT 6
- Fetch priority hint for dynamic modules
- a element defines content model as only Transparent HOT 1
- Severing a document's opener relationship regardless of origin HOT 17
- Video loading=lazy attribute support HOT 1
- Specify That Responsive Video Elements Re-Evaluate Sources on Media Change, Like Picture
- HTML Video: Allow a child Picture Element to Control the Video Poster Image HOT 1
- HTML Video and its Source Elements Should Support SRCSET and SIZES
- Upcoming WHATNOT meeting on 6/6/2024 HOT 2
- [Proposal] capture screen
- [Proposal] Capturing Real User Monitoring (RUM) HOT 1
- setTimeout() nesting levels: browsers do not match specification HOT 1
- Bug in timer initialisation steps: the id's of cleared but still live timers can be reused HOT 1
- The term "insertion point" HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from html.