Following my previous note iOS Switch State, since iOS now properly communicating state for a role="switch" (even if it is announced as a checked or unchecked “checkbox”), I wanted to revisit the JavaScript for my switch control component.

Recap of role="switch"

From the ARIA 1.1 specification:

A switch provides approximately the same functionality as a checkbox and toggle button, but makes it possible for assistive technologies to present the widget in a fashion consistent with its on-screen appearance.

and

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.

Announcements

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.

After checking out Andy Bell’s A progressive disclosure component, it inspired me to go back to the web components I’ve neglected, and dust off my switch web component (also on CodePen).

See the Pen Switch web component by Scott (@scottohara) on CodePen.

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:

More about expectations

Small update (04/04/2019), but there’s also this interesting Twitter thread about expectations for switches, started by Zoë Bijl: