3 ms·

> 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

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

seanwilson 3y ago
> 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.
- danShumway 3y ago
  > 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.

seanwilson 3y ago

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

danShumway 3y ago
> 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.