Dispatches From The Internets

While testing out a recent web component, I discovered the demo I’d built made active buttons totally inaccessible, but only on Android in dark mode. I was baffled because I intentionally use system colors in all my web components and their demos. In the browsers I’d been testing, the pair looked great in both dark and light themes, but over on my phone it was a different story.

In Chrome’s dark mode on Android, HighlightText is a mid-tone grey. Highlight is a mid-tone blue. The contrast was abysmal—a mere 1.98:1, failing all five contrast thresholds in the Web Content Accessibility Guidelines (WCAG). I wish I could say it was the first time I’d stumbled on this kind of issue. A week or so earlier, a user reported similar trouble in my tabbed interface demo with Windows in forced-color mode. I’d mistakenly thought forced-color mode was the primary issue. It wasn’t.

In both cases, I’d expected colors named for foreground and background roles to work together. Apparently, that was asking too much.

These experiences prompted me to build the System Color Study: a resource for comparing browser-provided colors and their intended pairings across browsers, operating systems, and preferences. I’m using it to inform my component work; I hope it’ll help you too.

If you’ve used the theme switcher on this site, you may notice it works a little differently now.

There’s been a lot of discussion lately about whether theme controls should offer two states or three. Bramus has made the case for three states, while Lea has argued that two are enough.

That discussion prompted me to revisit the way I’ve been managing themes on this site. I’d supported two themes—dark and light—and neglected the system setting entirely. I wanted to rectify that and felt the urge to build a web component to make it reusable: <theme-switcher>.

Back in 2022, I wrote “There can be only one: Options for building ‘choose one’ fields” for HTMHell. The interaction sounds simple—pick one option from a list—but choosing the right HTML control involves a few tradeoffs.

A <select> is compact, but you generally need to open it to see the available choices. Radio buttons put all the options in front of you, making them easier to scan and compare, but the group typically requires more screen real estate.

What if we could maintain visibility while presenting the choices in a more compact way?

That’s where <form-multi-switch> comes in. It presents a radio group as connected segments: all the options remain visible, but a short set of labels can fit neatly into a single row. Under the hood, they’re still native radio buttons, retaining their accessibility and UI affordances.

In an internal analysis of accessibility bugs, a colleague found that roughly half could be traced back to design decisions. These were issues we should have caught earlier, before those decisions became codified in code and long before anyone encountered them in a shipped product.

That’s one of the reasons I started working on Accessibility Assistant for Figma. I wanted to help designers catch issues while they worked and help them build their accessibility knowledge along the way. Version 53 brings more of that work together, organizing annotations, assessments, issues, and handoff around projects.

Many years ago, I made a little jQuery plugin called Easy Sortable Tables. It works exactly as promised: point it at a table and it upgrades the UI so a reader can sort the rows by clicking a column heading. The functionality is still useful, but I can’t even remember the last time I added jQuery to a site.

The web platform’s changed quite a bit since I wrote that plugin, so I decided to modernize it as a web component: <table-sortable>.