Following my previous note iOS Switch State, since iOS now properly communicating state for a
From the ARIA 1.1 specification:
switchprovides approximately the same functionality as a
button, but makes it possible for assistive technologies to present the widget in a fashion consistent with its on-screen appearance.
A type of checkbox that represents on/off values, as opposed to checked/unchecked values.
To expand on these points a bit, here is some additional context that I added to the readme of my switch control:
The expected user experience of a switch button is for an immediate action to take place. For instance, toggling a light/dark theme for a website or application, where the change instantly takes effect.
A checkbox, which is often found within a form, or in other UI where multiple elements can be checked, may not be understood to enact an immediate change to other elements in the document. That’s not to say additional information couldn’t be presented to the user to indicate such functionality, but it’s not a standard expectation. See potentially related WCAG success criteria “on input”.
A toggle button and switch are a bit more similar in that they both have an expectation for an immediate change from user interaction. Their primary differences revolve around the manner in which they are supposed to communicate state to assistive technology users, as well as the visual design they each may be most associated with.
As noted from the ARIA spec, a
role="switch" should announce itself as a “switch”, and whether it is in the “on” or “off” state.
With that in mind, as I noted in my iOS Switch State note and my A11y styled form controls: Switch Checkboxes documentation how the Switch is communicated to screen readers may vary quite a bit still. For instance, it may announce as specified, or as a “toggle button”, or “checkbox”, each with their own associated states.
Knowing that the
role="switch" may not be consistently announced, you should always test with real users to make sure the control’s intent is understood, especially noting situations where one user could be accessing the same content on different devices.
Switching it up for a minute…
I’ve been playing around with web components for a few months now, but I haven’t gotten around to posting anything about them.
Originally I had meant to make this a part of my 24ways 2018 post, but I just couldn’t coherently fit it into the article without going on a huge side tangent about custom elements.
I would still like to write a longer post about accessible web components in general. There are some quirks you should be aware of. But in the meantime I refer you to Andy’s previously mentioned post, as well as his helpful tatl repo, to start as a web component template.
And to wrap up this short note, I would be remiss if I didn’t mention that for more information, you should give the following resources a read:
- My testing and documentation of Checkbox switches (or not) and Toggle Button for potential alternatives to
- Under-Engineered Toggles by Adrian Roselli.
- On Designing and Building Toggle Switches by Sara Soueidan.
- Inclusive Components: Toggle Buttons by Heydon Pickering.
More about expectations
Small update (04/04/2019), but there’s also this interesting Twitter thread about expectations for switches, started by Zoë Bijl:
Switch, checkbox, or toggle button?— Zoë Bijl (@ZoeBijl) April 2, 2019
- Checkbox: this thing’s state is changed after I perform a save action
- Switch: this thing’s state is changed and saved after I interact with it
- Toggle button: this thing’s state is changed after I interact with it but it isn’t saved#ux