In native UI playing with a switch does not require confirmation. Settings are changed live. Is there precedent for that not happening?
I'm a bit worried we might end up encouraging some kind of UX pattern on the web that's not found in native by making this submittable.
I've been thinking about this since you posted it and I believe I've managed to wrestle my intuitions into something coherent.
HTML form-associated elements tie up a lot of different functionalities into one. Things such as:
(and probably more that are not as obvious from glancing at the spec, but that in practice authors depend on and use.)
The conflict here is that almost all of these are useful for switch, except for a couple. In particular, validation doesn't make too much sense. (But maybe custom validation still does?) And submission to the server encourages a pattern that doesn't align well with how switches are supposed to be used (according to the UX guidance linked in the explainer).
So I think the switch element should be form-associated, but I'm unsure whether it should have any submission value. I'd lean toward saying that it should have one: omitting it seems more likely to cause web developer confusion, and you can imagine it being useful to send the server the state of the switches alongside the state of other parts of the form (even if you also update the UI immediately, or send a quick out-of-band signal to the server, on switch change). But I'd like to hear more opinions.
If it does have a submission value, we should still have strong authoring guidance on making changes take place immediately. I'm just not sure whether omitting the submission value would encourage people to follow this guidance more.
In this comment it was suggested that the toggle switch immediately submits after being toggled.
That would actually be an accessibility violation against 3.2.2 On Input.
You need to submit a form using AJAX to avoid breaking that criterion when submitting forms on user input. That requires JS.
To facilitate submission without JS you could inherit from
<form> <input type="switch" formaction=“https://someurl.com/path” /> </form>
Alternative syntax (much like button):
<form> <switch formaction=“https://someurl.com/path”></switch> </form>
<input type=“submit” formaction=“https://someurl.com/path” />
Alternative Shadow DOM:
<button type=“submit” formaction=“https://someurl.com/path”></button>
Alternatively, you could inherit from a form element, omitting the need for the author to wrap the switch in a form element.
<switch method=“” action=“”></switch>
<form method=“” action=“”> <input type=“submit” /> </form>
HTML is supposed to be accessible by default so anything that suggests that it auto-submits when it changes isn't an option.
Not unless some fancy new native browser AJAX like functionality is also introduced. That would be opening a massive can of worms though that I don't think anyone wants to touch.
Anchor links auto submit a HTTP GET request when a user clicks on them. These are accessible elements. I would expect a toggle switch to perform a similar operation but allow POST, PATCH, PUT, DELETE etc as configurable HTTP request types.
So the question remains, would you expect to find a toggle switch as part of a form? why not use a checkbox instead? What semantics does a new toggle switch element inside a form give us?
I’m personally all for a toggle switch element but maybe not as a form element.
I think this does come down to good author guidance being written for the swtich.
However, there definitely is an argument to be made that a switch could still serve a purpose even within a more conventional form submission, and have author guidance to semantically differentiate it from a checkbox.