3 ms·
For me, the more common use case is to prevent users from making unnecessary mistakes. Only enable elements (like buttons) when all prerequisites are fulfilled.
by bradley13 3y ago
For me, the more common use case is to prevent users from making unnecessary mistakes. Only enable elements (like buttons) when all prerequisites are fulfilled. Simple example: if you require a user-name and password to login, then only enable the login button when that information is present.
This improves the experience for the vast majority of users; it prevents them from overlooking something, and having to go back later and fix it. If this makes life difficult for a very few? That's probably a worthwhile tradeoff.
Anyway, if you actually care about the people using screen readers, you should be offering them a separate experience anyway. One that doesn't involve JavaScript. Bet: the author of the article hasn't ever tried to use his fancy web-forms in Lynx.
- infotainment 3y ago> For me, the more common use case is to prevent users from making unnecessary mistakes. Only enable elements (like buttons) when all prerequisites are fulfilled. I’d argue this is actually worse UX, because in some cases (like a login form), it’s obvious, but in other cases, it might not be immediately clear to a user why the button is disabled. IMO it’s better UX to always enable the button, but provide clear messaging explaining 1) why the user couldn’t do the thing and 2) what needs to be fixed in order to do the thing
- xigoi 3y agoDisable the button and give it a tooltip or some text above it saying why it's disabled. I've seen this pattern and liked it.
- ghusbands 3y ago> Anyway, if you actually care about the people using screen readers, you should be offering them a separate experience anyway. That's a very odd claim. Pretty much nobody does that, and segregating people is not generally a good idea. You need to bake accessibility into everything you do. Screen readers and javascript work well enough together.