DEV Community: Marco Solazzi

A Journey through Switches

Marco Solazzi — Thu, 27 Feb 2025 05:45:36 +0000

Disclaimer: This post is just a record of my tests, investigations and speculations. Things might evolve and change as technology changes. Remember to verify your assumptions and test your code.

Some time ago, I learned about an interesting HTML pattern by wandering through the spec:

<label for="btn">Hello World</label>
<button type="button" id="btn"></button>

What I didn't know until then is that button is a labelable element and thus it can be referenced with the for attribute of a label.

Since this looked like an exotic pattern to me, I did some research and found that the pattern is actually well supported by browsers and most screen readers but not so well supported by voice control software (even if I couldn't verify it myself).

My initial guess was that, depending on the requirements, there are probably more established patterns out there, like using id and aria-labelledby. Nonetheless, this pattern stuck in my mind.

And then came The Switch

Now, the example above doesn't make much sense, and I didn't encounter it in the wild until recently when I found an implementation of it looking at the examples of the Switch component in the shadcn documentation (I cleaned it up to make it more readable):

<button 
    type="button" 
    role="switch" 
    aria-checked="false" 
    value="on" 
    id="airplane-mode"
>
</button>
<label for="airplane-mode">Airplane Mode</label>

The markup is very close to my first snippet, with the relevant addition of the switch role and the related aria-checked attribute. These additions tell assistive technologies that the control is a switch.

Around the web, you might find the control also called toggle or toggle switch, but this is how it would usually look like:

Since shadcn is based on Radix UI, a pretty established React library with a focus on accessibility, I decided to embark on a journey to see what other popular libraries were doing and how widespread the labeled button pattern was.

Introduction to switches

Before starting the journey, let's try to understand what a switch is, because the control itself is also pretty interesting from a User Experience point of view.

It clearly is a skeuomorphism of physical toggle switches and it was probably popularized by the iOS interface.

In many cases, the expected behavior for this control is to immediately have an effect on the system. For example, we expect a switch for airplane mode to immediately turn it on or off without having to press a save button.

This is where the application of this UI pattern to the web changes: a switch can both have immediate effect or be part of a submittable form (thus behaving almost like a checkbox). Let's keep this in mind for later.

Web switches

When it comes to the web, there's extensive literature about accessible switches and toggle buttons (for example: Updated Switch script & more, Toggle Buttons
, An accessible toggle).

Even if their semantics are slightly different, the names are used interchangeably in design systems.

There are two ongoing initiatives for native switch controls: OpenUI toggle and switch attribute, the latter one being already shipped in Safari 17.4. But for now, the most effective patterns are:

<!-- 1) HTML base is a checkbox -->  
<label for="switch">Airplane mode</label>
<input type="checkbox" id="switch" role="switch" aria-checked="false" />

<!-- 2) HTML base is a button -->
<label id="switch-label">Airplane mode</label>
<button aria-labelledby="switch-label" role="switch" aria-checked="false"></button>

Screen readers

For both patterns, NVDA and VoiceOver (macOS) and other screen readers would sound like (you can check it on CodePen):

Airplane mode off switch

Not all screen readers/browser pairs support these patterns though. For example, Narrator in every browser except Edge identifies the switch as button, off (probably because Narrator is mostly tailored for Edge users): as always, build with your target audience in mind.

System architecture

From a system architecture perspective, the first pattern is probably preferable in cases where the switch's state change is part of a submittable form. This is because the checkbox's value is submitted with all other fields (which is a good practice for progressive enhancement). This approach becomes even more relevant with concepts like React Server Functions.

The second pattern is instead more suitable when we want the state change to have an immediate effect since that's an expected behavior of the underlying button element.

The "labeled control side effect"

Another big difference, at least from the user agent point of view, is that in the first example the label has an associated labeled control (the checkbox), while in the second it's just a caption for the button.

It might seem a semantic subtlety, but there is a rather interesting side effect: interacting with the label of a labeled control triggers events on the control itself.

For example, in most browsers, clicking the label of a checkbox will change the checkbox's state, as if we directly clicked on the control. This is not the case when we associate a label and a control using aria-labelledby.

So, if we change the second snippet to:

<!-- 2) HTML base is a button -->
<label for="switch-btn">Airplane mode</label>
<button id="switch-btn" role="switch" aria-checked="false"></button>

now clicking on the label triggers the button click event (you can test the behavior in this CodePen).

In the context of a form with many inputs, this behavior might contribute to the consistency of the user experience by making the switch feel more native.

Anyway, as I previously mentioned, some accessibility software might not fully support this pattern. We'll see later how component libraries are trying to solve the problem.

Switches in the wild

Now that we've covered the basics of switches and their implementation patterns, I'd like to see what other popular component libraries are doing for the same component.

I will focus on React, Vue, and Angular since they seem to have the highest market share in the JavaScript ecosystem. My choice of library is a mix of surveys and other sources.

React Libraries

Library	Pattern
MUI	`label > input[type=checkbox]`
shadcn/ui + Radix Primitives	`label[for] + button[role=switch]`
Headless UI	`label[for] + button[role=switch][aria-labelledby]`
Chakra UI	`label > input[type=checkbox]`
React Aria	`label > input[type=checkbox][role=switch]` (no aria-checked)

Vue Libraries

Library	Pattern
Vuetify	`label[for] + input[type=checkbox]`
Element Plus	`label[for] + input[type=checkbox][role=switch]`
Radix Vue	`label[for] + button[role=switch][aria-label]`

Angular Libraries

Library	Pattern
Angular Material	`label[for] + button[role=switch][aria-labelledby]`
Nebular	`label > input[type=checkbox][role=switch]`

Multi-framework Libraries

Library	Pattern
Bootstrap	`label[for] + input[type=checkbox][role=switch]`
Prime(NG,React,Vue)	`label[for] + input[type=checkbox][role=switch]`
Ark UI	`label[for] + input[type=checkbox][aria-labelledby]`

Results

After investigating these libraries, a clear result emerges: as I suspected, most of the library authors chose a more conservative pattern using a label and a checkbox with (or without) the switch role.

However, even if it might seem that the label + button pattern isn't used a lot, we need to remember that React is the most popular JavaScript library, shadcn and Radix have large adoption, and Headless UI is used in Tailwind's own premium UI library.

So, from a numerical perspective, there may be a significant number of web applications using the labeled button pattern.

Accessibility testing results

In my quick tests using VoiceOver (macOS), NVDA, and Narrator, all these patterns worked as expected. The screen readers correctly reported switches and checkboxes along with their states, with one exception: NVDA on Firefox reports Element Plus as blank. I didn't investigate this issue in depth, but it might be related to how the library hides the native input element (see a similar topic for PrimeFaces).

Tests output log

MUI
- Safari 18 + VoiceOver: Airplane mode unchecked checkbox
- Chrome 133 + VoiceOver: Airplane mode unchecked checkbox
- Chrome 133 + NVDA 2024.1: Airplane mode checkbox not checked
- Firefox 135 + NVDA 2024.1: clickable Airplane mode checkbox not checked
- Edge 133 + Narrator: Airplane mode checkbox unchecked
shadcn/ui + Radix Primitives
- Safari 18 + VoiceOver: Airplane Mode off switch
- Chrome 133 + VoiceOver: Airplane Mode off switch
- Chrome 133 + NVDA 2024.1: Airplane Mode switch off
- Firefox 135 + NVDA 2024.1: Airplane Mode switch off
- Edge 133 + Narrator: Airplane Mode switch off
Headless UI
- Safari 18 + VoiceOver: Airplane mode off switch
- Chrome 133 + VoiceOver: Airplane mode off switch
- Chrome 133 + NVDA 2024.1: Airplane Mode switch off
- Firefox 135 + NVDA 2024.1: Airplane Mode switch off
- Edge 133 + Narrator: Airplane Mode switch off
Chakra UI
- Safari 18 + VoiceOver: Airplane mode unchecked checkbox
- Chrome 133 + VoiceOver: Airplane mode unchecked checkbox
- Chrome 133 + NVDA 2024.1: clickable Airplane mode checkbox not checked
- Firefox 135 + NVDA 2024.1: clickable Airplane mode checkbox not checked
- Edge 133 + Narrator: Airplane mode checkbox unchecked
React Aria
- Safari 18 + VoiceOver: Airplane mode off switch
- Chrome 133 + VoiceOver: Airplane mode off switch
- Chrome 133 + NVDA 2024.1: clickable Airplane switch off
- Firefox 135 + NVDA 2024.1: clickable Airplane switch off
- Edge 133 + Narrator: Airplane mode off switch
Vuetify
- Safari 18 + VoiceOver: Airplane mode unchecked checkbox
- Chrome 133 + VoiceOver: Airplane mode unchecked checkbox
- Chrome 133 + NVDA 2024.1: clickable Airplane mode checkbox not checked
- Firefox 135 + NVDA 2024.1: clickable Airplane mode checkbox not checked
- Edge 133 + Narrator: Airplane mode checkbox unchecked
Element Plus
- Safari 18 + VoiceOver: Airplane Mode off switch
- Chrome 133 + VoiceOver: Airplane Mode off switch
- Chrome 133 + NVDA 2024.1: clickable Airplane Mode switch off
- Firefox 135 + NVDA 2024.1: blank
- Edge 133 + Narrator: Airplane Mode switch off
Radix Vue
- Safari 18 + VoiceOver: Airplane mode off switch
- Chrome 133 + VoiceOver: Airplane mode off switch
- Chrome 133 + NVDA 2024.1: Airplane Mode switch off
- Firefox 135 + NVDA 2024.1: Airplane Mode switch off
- Edge 133 + Narrator: Airplane Mode switch off
Angular Material
- Safari 18 + VoiceOver: Airplane Mode off switch
- Chrome 133 + VoiceOver: Airplane Mode off switch
- Chrome 133 + NVDA 2024.1: Airplane Mode switch off
- Firefox 135 + NVDA 2024.1: Airplane Mode switch off
- Edge 133 + Narrator: Airplane Mode switch off
Nebular
- Safari 18 + VoiceOver: Airplane Mode off switch
- Chrome 133 + VoiceOver: Airplane Mode off switch
- Chrome 133 + NVDA 2024.1: Airplane Mode switch off
- Firefox 135 + NVDA 2024.1: clickable Airplane Mode switch off
- Edge 133 + Narrator: Airplane Mode switch off

I created some rough demo environments, grouping most of the libraries I tested. You can check them out at the following links:

I also noticed some interesting details:

MUI, Vuetify, and Chakra UI (as well as Ark UI, which is developed under the same org) implementations of the switch are basically just visual: the underlying controls are simply labeled checkboxes. While this makes the accessibility information less consistent with its on-screen appearance, as MUI documentation states, the choice of not using the switch role is conservative, to widen the range of supported devices.
React Aria doesn't set the aria-checked attribute that should be required; nevertheless, in all my tests, screen readers were able to pick the state from the underlying checkbox.
Headless UI and Angular Material use the same implementation as shadcn/ui (the labeled button) but with a twist: they introduce a redundancy where the label is referenced in the button via the aria-labelledby attribute.

Redundant labeling

The redundant labeling pattern from the previous section deserves a closer look, as it represents an interesting approach to usability and accessibility.

Here is a simplified snippet as reference:

<label for="switch" id="switch-label">Airplane mode</label>
<button id="switch" role="switch" aria-labelledby="switch-label" aria-checked="false"></button>

Earlier we said that some accessibility software might not properly compute the name of buttons associated with labels with the for attribute, so, since aria-* attributes have precedence in the computation of accessible names, we should have solved those issues.

The for attribute is then only used to leverage the labeled control trigger side effect (as reported in this PR).

Anyway, I couldn't test the accessibility of this pattern, so I can't 100% vouch for it.

Takeaways

After this long journey through switch implementations, I can summarize my findings in four key insights:

The labeled button pattern, while fascinating to discover in the HTML spec, remains somehow exotic in practice. However, its usage with a redundant labeling could make it a fair alternative to more traditional patterns.
Because UI libraries abstract away the HTML implementation, you end up living in a world (that of <Switches />, <Tabs /> and <Menubar />) disconnected from the real medium you're writing for: In all the test scenarios you are writing a variation on <Switch /> but the real markup is hidden away.
When we delegate our design choices to someone else, we don't know the impact on the user experience. Small changes in the markup can fundamentally change how users perceive and interact with an interface.
The libraries I explored emphasize their accessibility and indeed provide a good baseline, but as we've seen, there are often many possible ways to make a control "accessible" — each with its own assumptions and caveats. Don't rely blindly on any library; do some research based on your specific needs.

Originally posted at: https://marco.solazzi.me/blog/journey-through-switches/

Not Everything Needs a Component

Marco Solazzi — Mon, 25 Nov 2024 00:00:00 +0000

In the early 2000s, a new term, Divitis, was coined to refer to The practice of authoring web-page code with many div elements in place of meaningful semantic HTML elements. This was part of an effort to increase awareness of semantics in HTML within the frame of the Progressive Enhancement technique.

Fast forward 20 years - I witness a new syndrome affecting web developers, one I call componentitis. Here is my made-up definition:

Componentitis: the practice of creating a component for every aspect of a UI in place of a simpler and more reusable solution.

Components

So, first of all, what is a component? I think React popularized the term to refer to its building blocks:

React lets you combine your markup, CSS, and JavaScript into custom "components", reusable UI elements for your app.
— React documentation - Your First Component

While the concept of reusable UI elements wasn’t new at the time (in CSS, we already had techniques like OOCSS, SMACSS, and BEM), the key difference is its original approach to the location of markup, style, and interaction. With React components (and all the subsequent UI libraries), it’s possible to co-locate everything in a single file within the boundaries of a component.

So, using Facebook’s latest CSS library Stylex, you could write:

import * as stylex from "@stylexjs/stylex";
import { useState } from "react";

// styles
const styles = stylex.create({
    base: {
        fontSize: 16,
        lineHeight: 1.5,
        color: "#000",
    },
});

export function Toggle() {
    // interactions
    const [toggle, setToggle] = useState(false);
    const onClick = () => setToggle((t) => !t);

    // markup
    return (
        <button {...stylex.props(styles.base)} type="button" onClick={onClick}>
            {toggle}
        </button>
    );
}

You can be a fan or not of writing CSS in object notation (I’m not), but this level of co-location is often a good way to make a component-based project more maintainable: everything is within reach and explicitly bound.

In libraries like Svelte, the co-location is even more clear (and the code more concise):

<script>
    let toggle = $state(false)
    const onclick = () => toggle = !toggle
</script>

<button type='button' {onclick}>
    {toggle}
</button>

<style>
button {
    font-size: 16px;
    line-height: 1.5;
    color: #000;
}
</style>

Over time, this pattern has gained so much traction to the point that everything is encapsulated in components. You have probably encountered page components like this:

export function Page() {
    return (
        <Layout>
            <Header nav={<Nav />} />
            <Body>
                <Stack spacing={2}>
                    <Item>Item 1</Item>
                    <Item>Item 2</Item>
                    <Item>Item 3</Item>
                </Stack>
            </Body>
            <Footer />
        </Layout>
    );
}

Co-location of one

The above code looks clean and consistent: we use the component interface to describe a page.

But then, let’s look at the possible implementation of Stack. This component is usually a wrapper to ensure all direct child elements are vertically stacked and evenly spaced:

import * as stylex from "@stylexjs/stylex";
import type { PropsWithChildren } from "react";

const styles = stylex.create({
    root: {
        display: "flex",
        flexDirection: "column",
    },
    spacing: (value) => ({
        rowGap: value * 16,
    }),
});

export function Stack({
    spacing = 0,
    children,
}: PropsWithChildren<{ spacing?: number }>) {
    return (
        <div {...stylex.props(styles.root, styles.spacing(spacing))}>
            {children}
        </div>
    );
}

We only define the styles and the root element of the component.

In this case, we could even say that the only thing we are co-locating is the style block since the HTML is only used to hold a CSS class reference, and there is no interactivity or business logic.

The (avoidable) cost of flexibility

Now, what if we want to be able to render the root element as a section and maybe add some attributes? We need to enter the realm of polymorphic components. In React and with TypeScript this might end up being something like the following:

import * as stylex from "@stylexjs/stylex";

type PolymorphicComponentProps<T extends React.ElementType> = {
    as?: T;
    children?: React.ReactNode;
    spacing?: number;
} & React.ComponentPropsWithoutRef<T>;

const styles = stylex.create({
    root: {
        display: "flex",
        flexDirection: "column",
    },
    spacing: (value) => ({
        rowGap: value * 16,
    }),
});

export function Stack<T extends React.ElementType = "div">({
    as,
    spacing = 1,
    children,
    ...props
}: PolymorphicComponentProps<T>) {
    const Component = as || "div";
    return (
        <Component
            {...props}
            {...stylex.props(styles.root, styles.spacing(spacing))}
        >
            {children}
        </Component>
    );
}

In my opinion, this isn't very readable at first glance. And remember: we are just rendering an element with 3 CSS declarations.

Back to the basics

A while back, I was working on a pet project in Angular. Being used to thinking in components, I reached out to them to create a Stack. It turns out that in Angular polymorphic components are even more complex to create.

I started to question my implementation design and then I had an epiphany: why spend time and lines of code on complex implementations when the solution had been right in front of me all along?

<div class="stack"> 
</div>

.stack {
  --s: 0;
    display: flex;
    flex-direction: column;
    row-gap: calc(var(--s) * 16px);
}

Really, that’s the barebone native implementation of the Stack . Once you load the CSS in the layout, it can be used right away in your code:

export function Page() {
    return (
        <Layout>
            <Header nav={<Nav />} />
            <Body>
                <div className="stack" style="--s: 2">
                    <Item>Item 1</Item>
                    <Item>Item 2</Item>
                    <Item>Item 3</Item>
                </div>
            </Body>
            <Footer />
        </Layout>
    );
}

Let's see the main advantages of this approach:

reusability
reduced complexity
smaller JavaScript bundle and less overhead
interoperability

The last point is easy to overlook: Not every project uses React, and if you’re including the stack layout pattern in a Design System or a redistributable UI library, developers could use it in projects using different UI frameworks or a server-side language like PHP or Ruby.

Nice features and improvements

From this base, you can iterate to add more features and improve the developer experience. While some of the following examples target React specifically, they can be easily adapted to other frameworks.

Control spacing

If you're developing a component library you definitely want to define a set of pre-defined spacing variants to make space more consistent. This approach also eliminates the need to explicitly write the style attribute:

.stack {
  --s: 0;
  display: flex;
  flex-direction: column;
  row-gap: calc(var(--s) * 16px);

  &.s\:1 { --s: 1 }
  &.s\:2 { --s: 2 }
  &.s\:4 { --s: 4 }
  &.s\:6 { --s: 6 }
}

/** Usage:
<div class="stack s:2">
</div>
*/

For a bolder approach to spacing, see Complementary Space by Donnie D'Amato.

Add better scoping

Scoping, in this case, refers to techniques to prevent conflicts with other styles using the same selector. I’d argue that scoping issues affects a pretty small number of projects, but if you are really concerned about it, you could:

Use something as simple as CSS Modules, which is well supported in all major bundlers and frontend frameworks.
Use cascade layers resets to prevent external stylesheets from modifying your styles (this is an interesting technique).
Define a specific namespace like .my-app-... for your classes.

Here is the result with CSS Modules:

.stack {
  --s: 0;
  display: flex;
  flex-direction: column;
  row-gap: calc(var(--s) * 16px);

  &.s1 { --s: 1 }
  &.s2 { --s: 2 }
  &.s4 { --s: 4 }
  &.s6 { --s: 6 }
}

/** Usage
import * from './styles/stack.module.css'

<div className={`${styles.stack} ${styles.s2}`}>
    // ...
</div>  
*/

Add type-safety in JavaScript frameworks

The CSS-only solution provides neither typing nor IDE auto-completion.

Also, if we are not using spacing variants, it might feel too verbose to write both a class and a style attribute instead of a spacing prop. Assuming you're using React, you could leverage JSX and create a utility function:

function stack({ spacing }: { spacing: number }) {
    return { 
        className: 'stack', 
        style: { '--s': spacing } as React.CSSProperties 
    }
}

/* Usage:
<div {...stack({ spacing: 2 })}>
    // ...
</div>  
*/

Note that React TypeScript doesn’t allow unknown CSS properties. I used a type assertion for brevity, but you should choose a more robust solution.

If you’re using variants you can modify the utility function to provide a developer experience similar to PandaCSS patterns:

export function stack({ spacing }: { spacing: 0 | 1 | 2 | 4 | 6 }) {
  return `stack s:${spacing}`
}

/* Usage:
<div className={stack({ spacing: 2 })}>
    // ...
</div>  
*/

Prevent code duplication and hardcoded values

Some of you might have noticed that, in the last example, I hardcoded the expected values of spacing in both the CSS and the utility files. If a value is removed or added, this might be an issue because we must keep the two files in sync.

If you’re building a library, automated visual regression tests will probably catch this kind of issue. Anyway, if it still bothers you, a solution might be to reach for CSS Modules and either use typed-css-modules or throw a runtime error for unsupported values:

.stack {
  --s: 0;
  display: flex;
  flex-direction: column;
  row-gap: calc(var(--s) * 16px);

  &.s\:1 { --s: 1 }
  &.s\:2 { --s: 2 }
  &.s\:4 { --s: 4 }
  &.s\:6 { --s: 6 }
}

import styles from './stack.module.css';

export function stack({ spacing }: { spacing: number} = {}) {
const modifier = styles['s:' + spacing]
  if (!modifier) {
    throw new Error('Spacing value not supported: ' + spacing)
  }
  return `${styles.stack} ${modifier}`
}

Alternatives

If you still think a polymorphic component would be better, really can't deal with plain HTML, or don’t want to write CSS in a separate file (though I am not sure why), my next suggestion would be to take a look at PandaCSS and create custom patterns or explore other options like vanilla-extract. In my opinion, these tools are an over-engineered CSS metalanguage but still better than a polymorphic component.

Another alternative worth considering is Tailwind CSS, which has the advantage of being interoperable between languages and frameworks.

Using the default spacing scale defined by Tailwind, we could create a stack- plugin like this:

import plugin from 'tailwindcss/plugin'

/** @type {import('tailwindcss').Config} */
export default {
  content: [],
  theme: {
    extend: {},
  },
  plugins: [
    plugin(function({ matchComponents, theme }) {
        // dynamic component
        // will match stack-0, stack-1, stack-4, ... 
      matchComponents({
        'stack': (value) => ({
          display: 'flex',
          flexDirection: 'column',
          rowGap: `${value}`,
        }),
      }, { 
        values: theme('spacing')
      })
    })
  ],
}

/* Usage:
<div className="stack-2">
    // ...
</div>  
*/

As a side note: it's interesting that Tailwind uses the component mental model in matchComponents to describe complex CSS rulesets, even if it does not create any real component. Maybe another example of how pervasive the concept is?

Takeaways

The case of Componentitis, beyond its technical aspects, demonstrates the importance of pausing to examine and question our mental models and habits. Like many patterns in software development, components emerged as solutions to real problems, but when we began defaulting to this pattern, it became a silent source of complexity. Componentitis resembles those nutritional deficiencies caused by a restricted diet: the problem isn't with any single food but rather with missing out on everything else.