Speaking of buttons on the web… keyboard buttons this time.
Stop mapping custom shortcuts, especially those that override my browser standard shortcuts. Like, leave my Ctrl+P (print) alone, and Ctrl+U (view source), and others. Very few websites really need to have their own keyboard shortcuts and when they do it should be opt-out and -in.
Browser games (or alike) should read scancodes (KeyboardEvent.code) instead of their char values (KeyboardEvent.key), because your WASD (I don’t mind HJKL, though) does not work on non-QWERTY layouts like Dvorak, AZERTY, Colemak, etc.
Just a rant (-: Although, if someone knows articles on these a11y issues in a style akin to the OP, please share.
The latest update to GitHub hijacked the default keys for tab navigation in Safari (command-shift-left/right) to do… something. I actually have no idea what they do, they just don’t do the thing that they do in every other tab. There is a special circle of hell reserved for whoever made that decision.
One of the most annoying things about client-side rendered apps in terms of UX for me is that I often can’t Ctrl+Click to open links in new tabs because often these apps decide to write their own click handlers for links for some reason (tracking?). And almost no one thinks to check for the Ctrl or Shift keys.
Oh, that one too, yes. I mean, I have a whole list of all sorts of complains about the state of the modern web. I just didn’t want to chat off-topic too much. The button was the trigger (-:
For one, have a look at links on a Google search results page. They don’t break link UX in a way you describe, but they do a (necessary evil?) trick to track results: they let you see a real link, but change its href right when you click it, thus leading your request to their server first — https://i.imgur.com/kLYw0ik.jpeg
Websites don’t need keyboard shortcuts, but webapps, or apps in general do. I’ve been trying to figure out a way to find shortcuts that don’t overlap or ways to make them configurable with sane defaults. Anyone know of good resources?
Not a resource per se, but Hetzner Cloud’s console has a global shortcut whereas if you click on any of the red buttons that would prompt you for confirmation (think deletes, firewall edits…) while pressing down shift, it doesn’t prompt.
That’s how I like my shortcuts: not too fancy, global, non interfering, and ultimately make me more efficient. Unlike Confluence.
My pet peeve with disabled buttons is that there is always some complex validation logic in Javascript behind it. Sometimes that logic has bugs. So even after filling out the form, the button won’t get enabled again. When that happens, it is a nightmare. More so if I have to book tickets on a short notice. I workaround it by going to inspector and changing the state of the button in HTML.
If only I had a dollar for every time a button remained disabled for me … granted I couldn’t buy a car with it but I could buy a coffee with it sometimes.
Buggy or fragile client-side validation is one of my bêtes noires. Recently, I was trying to pay a bill, and it told me that I couldn’t submit the page without a particular field filled; the field in question didn’t appear anywhere on the form, and upon inspection turned out to be an <input type=“hidden”>. I ended up filling its value in the developer tools and then submitting. Gods forbid anyone who’s not a web developer try to send them money.
The out-of-the-box behavior of disabled buttons and inputs is pretty atrocious, both from an accessibility standpoint and from a usability standpoint. This article talks about a very specific situation in which a developer might be tempted to disable a form submit button to prevent duplicate submissions. However, there are many other cases where a button should be disabled but still be focusable.
Taking the form from the article’s the example, say a user entered invalid or incomplete content. They should not have to press the submit button to learn that it doesn’t work. It should look disabled and it should also be possible to show a tooltip on focus and hover saying why it’s disabled. This is currently impossible with the disabled attribute.
… say a user entered invalid or incomplete content. They should not have to press the submit button to learn that it doesn’t work.
If that’s what you want, then you are not wrong (about the tooltip). But disabling a button in general isn’t great. To quote my favorite website:
Do not validate when the user moves away from a field. Wait until they try to move to the next part of the service - usually by clicking the ‘continue’ or ‘submit’ button at the bottom of the page.
and from the section after
Only add client side validation if you find a user need for it. For example, because research shows it helps the user if you validate the information they’re providing as they type.
I apologize for being the “well acchhtually” guy if you didn’t mean anything by it. The certainty in your wording just triggered me a bit. It is really really difficult to do forms right and there is no one correct way (disabling the submit button certainly isn’t it).
My favourite example of this: the ACM Digital Library now requires you to enter an ORCID for every author in a paper. You cannot save state until you have entered every author’s ORCID (so make sure that you know them up front). You cannot paste these 16-digit numbers because their validation JavaScript intercepts every keypress and breaks paste. Oh, and you can’t disable JavaScript because the submit button is JavaScript.
It seems that the real bug is that you cannot focus disabled buttons. On the other hand, you also cannot properly focus or hover buttons on mobile (so no tooltip) and just not disabling the button and displaying a useful error when people press it is often a good solution.
Disabled elements also don’t submit anything to the server, which can be annoying. The two behaviors being combined is less than ideal.
But I hate disabled elements. In my homemade minigui library, I refused to even implement the feature at all for a while, then when users demanded it, I also added a string disabledReason which could be presented to the user when then try to use it…. but I left the disabled thing unimplemented everywhere except Windows still anyway where it just does the (bad) native behavior.
Just as a user, when I see something I want to do and it won’t let me, I’d at least like to know why it won’t let me; what I need to do so it will let me.
Speaking of buttons on the web… keyboard buttons this time.
Stop mapping custom shortcuts, especially those that override my browser standard shortcuts. Like, leave my Ctrl+P (print) alone, and Ctrl+U (view source), and others. Very few websites really need to have their own keyboard shortcuts and when they do it should be opt-out and -in.
Browser games (or alike) should read scancodes (KeyboardEvent.code) instead of their char values (KeyboardEvent.key), because your WASD (I don’t mind HJKL, though) does not work on non-QWERTY layouts like Dvorak, AZERTY, Colemak, etc.
Just a rant (-: Although, if someone knows articles on these a11y issues in a style akin to the OP, please share.
The latest update to GitHub hijacked the default keys for tab navigation in Safari (command-shift-left/right) to do… something. I actually have no idea what they do, they just don’t do the thing that they do in every other tab. There is a special circle of hell reserved for whoever made that decision.
One of the most annoying things about client-side rendered apps in terms of UX for me is that I often can’t Ctrl+Click to open links in new tabs because often these apps decide to write their own click handlers for links for some reason (tracking?). And almost no one thinks to check for the Ctrl or Shift keys.
Oh, that one too, yes. I mean, I have a whole list of all sorts of complains about the state of the modern web. I just didn’t want to chat off-topic too much. The button was the trigger (-:
For one, have a look at links on a Google search results page. They don’t break link UX in a way you describe, but they do a (necessary evil?) trick to track results: they let you see a real link, but change its href right when you click it, thus leading your request to their server first — https://i.imgur.com/kLYw0ik.jpeg
Websites don’t need keyboard shortcuts, but webapps, or apps in general do. I’ve been trying to figure out a way to find shortcuts that don’t overlap or ways to make them configurable with sane defaults. Anyone know of good resources?
I was reluctant to write webapps. (Must be my subjective attitude towards moving stuff into web browsers.)
Is there a clear distinction between sites and app, perhaps? Intuitively,
Still, is there a technical criterion, though? Or is it like it used to be DHTML – HTML that has any JS touching page’s DOM?
Not a resource per se, but Hetzner Cloud’s console has a global shortcut whereas if you click on any of the red buttons that would prompt you for confirmation (think deletes, firewall edits…) while pressing down shift, it doesn’t prompt.
That’s how I like my shortcuts: not too fancy, global, non interfering, and ultimately make me more efficient. Unlike Confluence.
There is the HTML attribute
accesskey, although MDN seems to be down on it. I think Wikipedia’s keyboard shortcuts use it.[Comment removed by author]
My pet peeve with disabled buttons is that there is always some complex validation logic in Javascript behind it. Sometimes that logic has bugs. So even after filling out the form, the button won’t get enabled again. When that happens, it is a nightmare. More so if I have to book tickets on a short notice. I workaround it by going to inspector and changing the state of the button in HTML.
If only I had a dollar for every time a button remained disabled for me … granted I couldn’t buy a car with it but I could buy a coffee with it sometimes.
Buggy or fragile client-side validation is one of my bêtes noires. Recently, I was trying to pay a bill, and it told me that I couldn’t submit the page without a particular field filled; the field in question didn’t appear anywhere on the form, and upon inspection turned out to be an <input type=“hidden”>. I ended up filling its value in the developer tools and then submitting. Gods forbid anyone who’s not a web developer try to send them money.
The out-of-the-box behavior of disabled buttons and inputs is pretty atrocious, both from an accessibility standpoint and from a usability standpoint. This article talks about a very specific situation in which a developer might be tempted to disable a form submit button to prevent duplicate submissions. However, there are many other cases where a button should be disabled but still be focusable.
Taking the form from the article’s the example, say a user entered invalid or incomplete content. They should not have to press the submit button to learn that it doesn’t work. It should look disabled and it should also be possible to show a tooltip on focus and hover saying why it’s disabled. This is currently impossible with the
disabledattribute.If that’s what you want, then you are not wrong (about the tooltip). But disabling a button in general isn’t great. To quote my favorite website:
and from the section after
I apologize for being the “well acchhtually” guy if you didn’t mean anything by it. The certainty in your wording just triggered me a bit. It is really really difficult to do forms right and there is no one correct way (disabling the submit button certainly isn’t it).
My favourite example of this: the ACM Digital Library now requires you to enter an ORCID for every author in a paper. You cannot save state until you have entered every author’s ORCID (so make sure that you know them up front). You cannot paste these 16-digit numbers because their validation JavaScript intercepts every keypress and breaks paste. Oh, and you can’t disable JavaScript because the submit button is JavaScript.
I see you are a person of distinguished taste. :D
It seems that the real bug is that you cannot focus disabled buttons. On the other hand, you also cannot properly focus or hover buttons on mobile (so no tooltip) and just not disabling the button and displaying a useful error when people press it is often a good solution.
Disabled elements also don’t submit anything to the server, which can be annoying. The two behaviors being combined is less than ideal.
But I hate disabled elements. In my homemade minigui library, I refused to even implement the feature at all for a while, then when users demanded it, I also added a string disabledReason which could be presented to the user when then try to use it…. but I left the disabled thing unimplemented everywhere except Windows still anyway where it just does the (bad) native behavior.
Just as a user, when I see something I want to do and it won’t let me, I’d at least like to know why it won’t let me; what I need to do so it will let me.