The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
This came up in a Slack discussion about the switch (aka, "toggle") for #3593539: [PP-1] Replace compact mode link with a switch to improve accessibility.
In the Default Admin theme, standard checkboxes on forms that require submission are styled as toggle switches.
Regarding accessibility, per #2 it is a failure of SC 1.3.1 Info and Relationships (Level A).
Regarding UX, Nielsen Norman Group says standard checkboxes should be used in cases that require form submission:
Toggle switches should take immediate effect and should not require the user to click Save or Submit to apply the new state. As always, we should strive to match the system to the real world. Consider my tea kettle: I should not have to flip the switch off and unplug the cord to experience the change in state. Consequently, users expect the same immediate results from a digital toggle as they do from their real-world counterparts (e.g., light switches). Immediate results are a facet of toggle switches that grants users the freedom and control to update their preferences as needed.
If immediate results are not achievable or seem ill-suited, an alternative (i.e. radio buttons or a single checkbox — see chart above) should be used instead. If you’re considering including toggles in long forms where other types of form fields are present, and users will need to click a Submit button for other changes to take effect, don’t. This scenario confuses users because they can’t be sure whether their toggle choice will take immediate effect. Avoid confusion at all costs. Separate controls that produce instant results from those that require clicking a command button.
Steps to reproduce
- Set Default Admin as the administration theme
- Go to any form that has boolean controls and requires the user to submit the form for changes to take effect, such as
/admin/appearance/settings.
Proposed resolution
Use normal checkboxes instead of toggle switches in these cases.
Remaining tasks
- Get review by the UX team.
- Convert these cases to appear as standard checkboxes. This may require CSS changes, so it may need to wait until the bulk of #3582351: [Meta] Clean up CSS within Admin theme is complete.
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | switch-not-checkbox.png | 65.7 KB | mgifford |
Issue fork drupal-3594809
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
cwilcox808 commentedCheckboxes are a kind of form element so the user's expectation is changes occur not when one is checked/unchecked but when the form it belongs to is successfully submitted (checkboxes may still have additional side effects, e.g. a set of checkboxes ends with "Other" that, when checked, reveals a text input for adding details).
Switches are more like buttons and with buttons the user's expectation is changes occur immediately when they're used.
Visually, user expectations are set by a control's appearance and non-visual expectations are set by a control's implicit (
<input type="checkbox">) or explicit (<input type="checkbox" role="switch">) ARIA role. The expectations set visually and non-visually should match for consistency and to not confuse the many screen reader users who have some vision. When visual information is not also conveyed non-visually (aka programmatically), it's a failure of WCAG Success Criterion 1.3.1 Info and Relationships ("Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.")Comment #3
kentr commentedThanks @cwilcox808.
The markup for these appears to be that of a plain checkbox, with no
role="switch".I'm classifying it as a failure of SC 1.3.1 Info and Relationships (Level A) per #2.
Comment #4
kentr commentedComment #5
kentr commentedComment #6
kentr commentedComment #7
kentr commentedInteresting that Adrian Roselli thinks it's OK to style standard checkboxes as switches in spite of the visual disconnect.
However, Scott O'Hara echos the concern of confusion between the different modes of operation from the same visual presentation:
Comment #8
kentr commentedAddendum to #8: #3593539: [PP-1] Replace compact mode link with a switch to improve accessibility proposes to use switch styling for an immediate-effect toggle control.
So, keeping the toggle switch styling of these standard checkboxes in that case would violate Scott O'Hara's recommendation.
It seems as though crossing between the admin theme and a default ("frontend") theme that uses standard checkbox styling would also cause this kind of confusion. It's definitely possible that a single user will encounter forms on both the admin and default themes.
Comment #9
mgiffordSome references to back this up.
Comment #10
mgiffordIsn't Scott O'Hara just saying "be consistent with use of switch vs checkbox in your UI". Inconsistency is a bigger challenge than if it looks like a switch or a checkbox.
Comment #12
kentr commentedI think using a switch for cases like #3593539: [PP-1] Replace compact mode link with a switch to improve accessibility would violate the consistency part of his recommendation.
It seems to me that also standard checkboxes in the front-end theme would violate it for the users who use both admin and front-end forms.
I tagged this with Needs usability review to get their input before it goes anywhere.
Now I know that they also filter on Needs review status, so I'm changing to Needs review for UX feedback (not for a review of the MR).
Comment #13
benjifisherI do not claim to be an expert on usability, nor accessibility, but it seems clear to me that there is always an ambiguity in a toggle. Does the "active" style of the toggle indicate the current state or does it indicate what will happen if you trigger the toggle?
When a toggle has an immediate, noticeable effect, the ambiguity is mitigated. You can toggle the state and see what happens. If nothing happens until the form is submitted, then there is no mitigation.
In general, the trend over the years has been to move away from trying to outsmart the browser designers. This approach has benefited from increasing functionality in browsers, new HTML elements, and evergreen browsers. This issue seems like part of that approach. I could also cite a slogan, like "keep it simple" (KISS) or "less is more".
Comment #14
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #15
cwilcox808 commentedA toggle switch's visual state should always indicate the current state. If a control, through its name and appearance, doesn't indicate it's current state, it should not be a switch.
I typically agree with Adrian Roselli but I disagree with the part of his Under-Engineered Toggles article that sanctions the use of toggle styles without toggle behavior. He states that using the ARIA "switch" role means it must take immediate effect; I think the visual toggle appearance makes the same implicit "promise" to be kept.
Open UI has an explainer for the proposed Switch attribute which Safari has already shipped and Chromium is adding behind a feature flag (I think the polyfill for the switch attribute is well-implemented). Using this checkbox attribute adds the switch role and default appearance but leaves implementation of the behavior (doing something that takes immediate effect) up to the developer.