Will browsers ever catch up here so that the right way to do it is the default way? Or at least one of the easiest ways?<p>It's clearly difficult if there's so many options and this generates so much discussion. It shouldn't be this hard to get a basic UI pattern right (submitting a form once with progress updates).<p>If it's even a little hard, it's inevitable 90% of sites will get it wrong. There's just too much stuff for devs to realistically stay on top of to blame them.<p>Related: the `inert` attribute has good support now for preventing users from editing/interacting with forms that are currently being submitted so you don't have to mess with overriding input events (<a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/inert" rel="nofollow noreferrer">https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...</a>). You'll have to add it manually when the form is submitted though, remove it if the submission fails, and use something like aria-live to give progress updates (<a href="https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-live" rel="nofollow noreferrer">https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...</a>). You'll also need to manually test all your custom forms like this work on actual screen readers (they have inconsistent behaviour, similar to cross-browser bugs), as well as edge cases like resubmitting after a failure, when the network request fails with error feedback, and when the network request fails from a time out. Not easy.
If accessibility tools remove the focus from the disabled button and focus the document instead when a button is disabled, wouldn't this be a problem of the accessibility tool in the first place?<p>Even just focussing the parent element would be a much much better idea than focusing the document.<p>Making a button <i>look</i> disabled without actuall disabling it sounds like a semantically bad idea.
Maybe pedantic, but OPs advise is actually "disable the button, but don't use the disable attribute to do it". Instead they store the disabled state in the form and set a CSS style to make the button look like a disabled button. Which makes that information unavailable to screen readers, but avoids screen readers jumping around the page because button loses focus when disabled.<p>Also a useful note that disabling the button with the disabled attribute isn't enough to prevent people from submitting a form. Which is useful to remember, but not actually a justification for any of this (you can just check the disabled state of the button in your submit method)
Similarly, don't disable submit buttons so you can wait for me to type something. Especially for login forms, many password managers don't type usernames and passwords, but some login forms wait for you to type something before they'll allow you to submit.
The article doesn't mention this, but if you are going to build your own disabled state, at the very least include an aria-disabled attribute on your button. See Mozilla docs on the subject, which mention this exact same scenario: <a href="https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-disabled" rel="nofollow noreferrer">https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...</a><p>Using pure-CSS and data-attributes without additional indicators doesn't help low-vision users; the only thing they'll be able to tell is that click doesn't work on some of your buttons, they won't be able to see the CSS or non-semantic attributes that say the button is disabled. If you're getting rid of browser semantics, you need to include the relevant aria semantics to compensate.
The article is right, but it’s also an indictment of just how poorly designed HTML is for dynamic applications.<p>Preventing double submission of data is a thoroughly basic feature for any UI library. It should be easy and obvious. But for HTML forms, the properly accessible solution shown here involves a non-intuitive combination of JavaScript, CSS and custom data attributes on an element.
Disagree. If it is currently invalid to click the button, disable it, that is what it is for. Disabled buttons should be focusable, that resolves the issue with disabling the focused button in response to a click. How you achieve this in any given environment is a different issue, if the out of the box disabled functionality does not work properly, you will have to find workarounds.
So you have focus on a button, which then becomes disabled, this throws focus back at the document level.<p>That sounds like a browser bug to me. It's absurd behavior. The focus change is as unhelpful as is humanly possible. It's not what the developer intended, it's not what anyone possibly would intend, so why is it the default behavior?<p>Same for "implementing an ARIA live region"<p>How about no? Developers are supposed to piece together hundreds of obscure articles to figure out the right way to build an accessible form. Most won't, but if they do, they're still not confident about its implementation.<p>How about after 30 years the web platform provides some elements that actually do something, with sane defaults instead of millions of developers being puzzled what to do for even the most basic of tasks?
It’s weird to see so many UX articles on the front page of HN that are just wrong.<p>Disabling buttons that are functionally no-ops is the semantically correct thing to do.
Good advice!<p>I go one step further with buttons in my own React UI library, and I wish all UI libraries did the same:<p>When a button is “disabled”, it should show why either on hover or on click.<p>It’s a common frustration in software, especially complex ones like Adobe Photoshop or Autodesk Fusion 360, where a button is disabled and you cannot figure out why. For example: you can’t fill because it’s a “smart layer” and you need to rasterise it. Or you can’t “join” because both CAD bodies are fixed.<p>The programs KNOW why the button is disabled — otherwise how would it know to disable the button! So show the user why!<p>This alone would save countless person-hours and reduce a lot of frustration.
Can we add an "AD" tag in HN?<p>Don't get me wrong but this really does not explain the full story and the post ends with basically: "If you really want to know pay for it".<p>I don't have anything about paying for this information but at least say it is an AD for your agency.
Stupid question - couldn't (shouldn't) form submission be sort of idempotent? That is, if the same thing gets submitted again, drop it on the server side, rather than doing all sorts of fancy stuff on the client?
If the problem is shifting focus to the document, is it not better to: before disabling the button, with the attribute, create an element that contains information about the action in progress and focus on this element via `element.focus();`, and then add the "disabled" attribute?
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.<p>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.<p>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.
It's an excellent point but perhaps the solution still doesn't solve the problems. Like, it fixes the problem for accessibility but then creates or leaves problems for user experience.
I agree with some of the perceived issues, but not entirely with the solution.<p>I think this is what state machines are for. The disabled attribute is in a sense part of the button's own state-oriented behaviours, but as mentioned it isn't really sufficient to prevent other interactions or submissions. You can prevent form submissions and/or ignore them by orchestrating form UI and interactions within a state machine, though.<p>It sounds complex, but it's an abstraction that can be easily reused across forms, and it's not an expensive abstraction. If you're using JS, it's a trivial addition that can provide easily tested, robust, reliable form behaviours that respect your users and your business logic.<p>I've wondered many times why something like <form id="my-form
disabled> isn't possible.
> If the button is the current item in focus when you add the disabled attribute (for example, if someone just pressed it to submit the form), the element actually loses focus, which shifts to the document element.<p>> For a screen reader user, this is particularly jarring, as now you’re in a totally different place on the page.<p>This just feels like an argument to abandon a very useful, well understood, and built-in tool (disabling to preventing double form submission) in order to make things better for a small subset of users of a particular tool.<p>Why can't this just be the problem of screen readers? Why is the "solution" to not use or remove a widely used and well understood web standard?
Is there a blogpost out there like "X things programmers don't understand about HTML forms"? In the same vain as the ones for names, character encoding, etc...<p>I'm sure there'd be a few humdingers in there.
For me the disabled button on a partially-valid Form say, is a metaphor-overload.<p>Whilst a physical button may be disabled to indicate being functional-but-not-ready, in software one doesn't have to show/display them until they are ready for action. If the Form is partially valid, show a Message instead of a Button, then when it is valid, pop the Action button clearly on display.<p>Personally I like to leave the button enabled, check the Action can be performed (form valid etc), and notify the User of errors, progress etc. It's better to communicate with the User exactly, than imply messages - it's a form, not a puzzle or an opportunity to play physical jokes on the User (gotcha, can't press this!).
It would be weird to avoid the only reason I have to use this button attribute. I thought the disabled state only existed to fix this problem. I can't find any other use that wouldn't end up being a complete UX mistake.
BS I say.<p>In a JS framework frontend I will disable the button on submit, so the form can't be submitted twice, because accidental double clicks happen.
I will enable it after at most 6 seconds or if the response is an error response.
Can we also talk about aggressively deleting form fields? Forgot password? Let me forget the email you just typed in when trying to login. Guessed the wrong password? I'll erase that field for you.
Amazon, of all places, had this defect in their login flow for the longest time which was only recently fixed.<p>It was so bad that when you were waiting for an SMS code, after you received it and autofilled it in iOS, their website and app would automatically submit the input, and so hitting submit on your keyboard would cause the backend to reprocess the code a second time, invalidating your login.<p>It was obvious someone slapped the implementation together and it was so embarrassing.<p>Yet, I’m still nonplussed that we keep screwing up forms.
Here's a similar take from Joel Spolsky:<p>A long time ago, it became fashionable, even recommended, to disable menu items when they could not be used.<p>Don’t do this. Users see the disabled menu item that they want to click on, and are left entirely without a clue of what they are supposed to do to get the menu item to work.<p>Instead, leave the menu item enabled. If there’s some reason you can’t complete the action, the menu item can display a message telling the user why.
Title is a bit broad for what the post actually talks about. There's plenty of good reasons to disable buttons, just not in this <i>particular</i> case.
We've been following that policy in our desktop application for a long time. It's almost always much better for the users that they get an error message saying why it's not possible to do X when they press the button, than not knowing why the button is disabled.
Disabling a button is not up for argument. You are entitled an opinion but you are wrong. As mentioned in the article, it becomes invisible for screen readers so, no, hard stop on its usage. From a usability standpoint, an available button gives you the opportunity to validate a users field, shortcut someone to that field and if you use form properly, allow the user to go on to the next invalid field with the enter key.
furthermore, on any app, don't disable a button when an action isn't available. you can still mark it as disabled via color, but if someone clicks on it, you should show them a message <i>WHY</i> that action isn't available. "Sorry, you haven't filled in your phone number", etc.
Allow me to hijack this thread to say something that is related:<p>Do not disable buttons or checkboxes or whatever unless it's very obvious how to enable them! I have seen software applications that showed disabled form controls or menu entries depending on settings that were in other screens or even compile-time settings - that is unacceptable!