Form-associated?

[annevk]

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.

[domenic]

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:

• Being disableable
• Being grouped into fieldsets (which can be disabled en masse)
• Being associated with <label>s
• Being resettable to their original states
• Being able to be submitted to the server
• Being subject to a submission/validation framework

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

[Dan503]

In this comment it was suggested that the toggle switch immediately submits after being toggled. https://discourse.wicg.io/t/proposal-a-toggle-switch-control-element/3620/3

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.

[ghost]

To facilitate submission without JS you could inherit from <input type=“submit”> to make use of the form action attribute for a <switch> element?

Example:

<form>
    <input type="switch" formaction=“https://someurl.com/path” />
</form>

Alternative syntax (much like button):

<form>
    <switch formaction=“https://someurl.com/path”></switch>
</form>

Shadow DOM:

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

Example:

<switch method=“” action=“”></switch>

Shadow DOM:

<form method=“” action=“”>
    <input type=“submit” />
</form>

[domenic]

None of those approaches get around the fundamental problem, though, that submitting a form is a full-page navigation that will throw away the current contents of the page. That isn't the behavior you want for a switch.

[annevk]

The server could reply with a 206, but yeah. For progressive enhancement it should probably be submittable, even if weird from a "native" perspective. I think if there's some text to contract this with checkboxes and such this is all good from my perspective.

[Dan503]

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.

[ghost]

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.

[scottaohara]

I think this does come down to good author guidance being written for the swtich.

Native mobile usage and JavaScript powered custom ARIA role=switch controls have largely created a precedent for instant submission (though from an a11y semantics standpoint role=switch still has some quirky support, which my hope is this element gaining traction would help resolve).

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.

For instance, "I agree to the terms of service / privacy policy." That's a checkbox. That is a yes/no that upon form submission is a one time answer. A switch could be used within a form as an indicator of an option that users could change their mind on at a later point. e.g. "do you want to receive marketing emails?" No I don't. But, it will be available to me as a configurable option in the app's settings. I won't change that setting... but i could.

There could then also be author guidance to indicate that a switch could be used with JavaScript to provide instantaneous changes to a screen/document or as a global setting, outside of a standard form submission, ala a toggle button, which the ARIA specification also relates a role=switch to.