`inert` has the exact same problem, and is arguably even worse since it removes content from the accessibility tree entirely:

> Specifically, inert does the following:

> Prevents the click event from being fired when the user clicks on the element.

> Prevents the focus event from being raised by preventing the element from gaining focus.

> Hides the element and its content from assistive technologies by excluding them from the accessibility tree.

An `inert` attribute is basically invisible to screenreaders, and if you have mitigations in place for that, you might as well just use `disabled`. So I advise against using `inert`, I'm not going to say it's completely useless, but I don't think there are ton of instances where it makes sense and it's easy to get wrong.

----

The real solution here is pretty obvious: `disabled` shouldn't block focus. It's not what users want in most situations, and there are easy ways to block focus from an element if it needs focus blocked. The problem is that it would probably be extremely complicated to change browser specs to implement the better behavior. Introducing another attribute that has the correct behavior would likely be easier, but it's still not going to be trivial to get that through standardization process.

But it's no great difficulty to block a button from being focusable in HTML, that's easy. We're only in this position because `disabled` blocks focus by default and offers no way to get focus back. Even manually setting a `tabindex` does nothing. And that's just bad design, clearly there are situations where disabled buttons should be able to receive focus. If not the default behavior, it should at least be possible to allow focus as an override.

Seems like the best option may be to add the disabled attribute to the button, as well as provide an aria-live section with a message stating that the form is in the process of submittal. Of course then you'll have to handle removing the disabled attribute, as well as providing a message either stating the submittal was successful, or that an error occurred.

I get that HTML wasn't supposed to be an application platform, but it's what we've got for now, and all we can do is work with what we have and keep pushing forwards for better standards or a better application delivery method (which is tough, since deployment as HTML is just so easy as compared to updating a rich client application).

To clarify, I only meant `inert` is another (fairly new) tool that can be useful, not a complete solution. For example, you can use it to prevent the user editing the fields of the form while the current field values are being submitted. You don't need to use it on the submit button.

As far as I remember, for similar behaviour you either have to add `disabled` to all the fields (then remember to revert only the `disabled` attributes you added if the form submit fails...) or wrap all the fields in a `disabled` `fieldset` tag (now you have to research if there's any quirks when you nest `fieldset`s).

Saying that, why keep the focus on the submit button? Are there no better alternatives?

> Saying that, why keep the focus on the submit button? Are there no better alternatives?

That is a good question. Probably not? I could be convinced otherwise, but I'm doubtful there's an obvious universal answer. If the form has an error, I suppose we can jump to the error field. If the form is successful, maybe we remove it from the DOM entirely? But both of those are situational and I don't feel confident that there's a universal answer.

And my instinct is (I might be wrong on this) that moving focus around automatically may just be disorienting to blind/low-vision users anyway and we should be cautious about doing so.

The current situation is I think the worst of all worlds. If a developer has the presence of mind to move the focus to another element, great. But if they don't think to do so, currently `disabled` just kind of dumps the focus, and that really feels like the worst outcome. To me, graceful degradation would be "we're going to keep you focused on the element you've selected unless the developer takes active steps to move your focus elsewhere."

The accessibility shouldn't completely fall over if the developer makes an accessibility mistake, there should be serviceable defaults for pages where developers put no extra effort into accessibility.

----

And even if we can figure out a universal standard for form behavior, buttons are used outside of forms, and `disabled` affects them there as well. If we want an accessible standard for where to move focus when a form submits, that should be a browser event that gets triggered off of the form submit event. Then it would be properly overridable with `preventDefault`, it would respond correctly to submit events even if the form button is left enabled.

It shouldn't be a result of the disabled buttons being unselectable, if it's a form-specific behavior it should be `form` behavior, not `button` behavior.

----

> To clarify, I only meant `inert` is another (fairly new) tool that can be useful, not a complete solution. For example, you can use it to prevent the user editing the fields of the form while the current field values are being submitted. You don't need to use it on the submit button.

Fair, but I personally would advise against this (although I'm open to other feedback if people have it) -- I don't think removing the form from the accessibility tree is a good response to an in-progress submit. I often like to compare with the visual UX when thinking about low-vision UX. If removing the form is the best option, then why wouldn't we full-on remove the form by setting it to `display: none`? I think the reason is that we recognize that hiding content from the page in response to an in-progress submission and then reintroducing that content based on error/success messages is bad visual UX.

So my feeling is that if it's important for a sighted user to be able to still see the form, then in most cases it's also probably important for a low-vision user to be able to access the form contents (but not edit them).

Remember that screenreaders and keyboard controls will respect `display: none`. So the only time we're using `inert` is for situations where we want content to be invisible to screenreaders but not to sighted users. And I just think that's a situation we should be very cautious about, typically the only time I'm trying to hide content from screenreaders is things like icon elements, tiny elements that shouldn't be read aloud, and usually I still want those elements to have some kind of label or reference anyway.

> If the form has an error, I suppose we can jump to the error field.

Yep, that's standard good practice I think for all users.

> If removing the form is the best option, then why wouldn't we full-on remove the form by setting it to `display: none`? I think the reason is that we recognize that hiding content from the page in response to an in-progress submission and then reintroducing that content based on error/success messages is bad visual UX.

So a common pattern right now to indicate the form is being submitted and it's going to take a moment is to fade out the form or the entire screen a little. And if it's going to take a few seconds, show a spinner, progress bar or progress message as well. `display: none` would look very jarring like the page just crashed. On a screen reader, you would want to announce the submission happened and the live progress, which you could get with little effort by wrapping the visual progress indicator with `aria-live`.

I agree to be cautious here but I'm not seeing a problem. I'm also not seeing the reason behind keeping the focus on the submit button when you can't interact with it now.

> I'm also not seeing the reason behind keeping the focus on the submit button when you can't interact with it now.

So let me complicate this a little bit because we're not talking about an immediate focus-change. It's not that a user clicks submit and immediately they should jump to the error field, there is a period of time where the form is being submitted and that's the only thing happening.

The question is, where should the focus go during that period?

Currently, if you do error-focusing then unless you also program handling for the progress event (which we'll get to below) what happens is the focus is on the button, then it's on the document, then it's back to the error. What I'm suggesting is that's pretty jarring, and it seems like the focus really should stay on the button until the developer is ready to move it elsewhere.

And you can move the focus anywhere else you want whenever you want, that's already easy to do, but if you forget to do so and you forget to account for the focus change, then dropping the user focus and throwing it onto the document is a really bad failure state.

And even if you do have progress-bar handling, for example in your fadeout example, if an immediate removal of the form is jarring to a visual user and they need a transition to make it more obvious what happened, then I would argue the same is true for a visually-challenged user.

While your form is fading out, maybe add an aria-live message that says submission is in progress, and by the time that message has finished being read out to a screenreader, the form will probably be finished fading and then you can move the focus wherever you want (assuming there is a good place to move it) and just remove the form from the DOM normally or set it to invisible in CSS, no extra attributes needed. This ends up being basically the same outcome as what you suggest, but I don't like this idea that we're going to kick focus to the document while we're waiting to put it somewhere else, and I don't like this idea that the browser is essentially saying "unless you have somewhere else better in mind to put the focus, then tough luck there is no focus anymore."

I buy that you might have situations where it makes sense to move the focus. I don't buy that outside of those situations the best default behavior for a browser is to drop the focus entirely and move it to the document. And while I'm more open to the idea, I also still sort of don't buy that situations that require visual transitions to improve UX for sighted users are good examples of when we should move focus immediately before giving a non-sighted user any feedback or heads up of what's happening.

----

As a side note, I do want to re-emphasize again as well, buttons are used outside of forms. If we want forms to push focus to the first errored field by default whenever a submission finishes, that really ideally would be default behavior for the `form` tag, not for buttons.

Form behavior should really not be dictating how focus events get handled for disabled buttons. The question is whether there's ever a use-case for focusing a disabled button (in or outside of a form) because right now it's impossible to do so. We can always get rid of focus from a button, but we can't put it back if the browser prevents focus entirely, so unless we're completely certain that we're never going to need to focus a disabled button, I don't think it makes sense to design an attribute in a way that forces that behavior.

`inert` is intended primarily to help with overlay focusing (think dialogs, drawers etc) or offscreen elements that should be hidden. While yes, it can be added to any element (and therefore make it and its subtree inert) which could enable some kind of novel use case, I think the standard case are primarily dialogs / overlays and offscreen elements that need to be hidden

I'm open to a use-case here that isn't obvious to me, I'm not saying you're wrong. But I don't understand why I wouldn't use `display: none` for an offscreen element or a hidden dialog/overlay? Screenreaders do skip over `display: none`, right?

If I'm moving an element offscreen but not full-on hiding it, in my experience 99% of the time it's because I want it to be visually hidden but still show up for a screenreader. `inert` gives me the opposite behavior by default. I'm trying to think when I've ever wanted an element to be visually hidden from both sighted users and a screenreader, but also couldn't do that via normal CSS.

Again, open to learning more, but this still seems to me like an attribute that should be generally avoided. I can think of some use-cases; maybe I have something like a chart where there are a lot of focusable elements but where the experience is awful for keyboard or screenreaders and I want to basically declare bankruptcy and say, "no, I don't want it to work with those controls at all, it might as well not exist for those people."

But those situations seem very rare to me.

fragment content that be moved to be visible but you don't want announced. Things like long form news articles where you might render the graphics with accompanying descriptions off screen (to save cycles) but as you scroll into view while reading you shift it to be visible.

Really its good for anything where you don't want the browser to "paint" but you want to have the content fully loaded without the user having any idea until you essentially want them to

Oh, that's a good point. Yeah, I can see it being useful for that.

> 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?

My pet peevee is how browsers; and later smartphones; normalized that interactive elements can reflow/reorganize all the time. Now, things like joining a specific WiFi, or mirropring to a specific TV, can become a game of chance if you don't let the UI settle a bit. We had this problem more or less solved before.

You're absolutely right. It took me years to spoon feed myself web development while on the clock. I don't think there's a proper path forward for learning HTML and everyone has different opinions. But learning about WCAG should come right after learning HTML and CSS. Study BEM and a CSS library. Then basic Javascript or framework basics follow by CSS and JS molecular design principals with JSON and fetching. Then apply HTML semantics to write user actor tests.

Anything I missed it's because I still haven't learned it so yes, it's a crazy world.