Three great examples of HTML web components:
What I hope is that you now have the same sort of epiphany that I had when reading Jeremy Keith’s post: HTML Web Components are an HTML-first feature.
This is a really lovely little HTML web component from Jason. It does just one thing—wires up a trigger button to toggle-able content, taking care of all the ARIA for you behind the scenes.
Maybe when I wrote about performative performance? Michelle has a prime example:
The low carbon toggle does absolutely nothing.
In fact, worse than nothing. It doesn’t prevent images being downloaded. It doesn’t switch the site to dark mode, or prevent autoplaying animations (e.g. the hero carousel), or reduce resources transferred in other way. All it does is overlay an extra element with a background gradient on top of the large images on the site to give the appearance that those images being prevented from loading.
Web Summer Camp in Croatia finished with an interesting discussion. It was labelled a town-hall meeting, but it was more like an Oxford debating club.
Two speakers had two minutes each to speak for or against a particular statement. Their stances were assigned to them so they didn’t necessarily believe what they said.
One of the propositions was something like:
In the future, sustainable design will be as important as UX or performance.
That’s a tough one to argue against! But that’s what Sophia had to do.
She actually made a fairly compelling argument. She said that real impact isn’t going to come from individual websites changing their colour schemes. Real impact is going to come from making server farms run on renewable energy. She advocated for political action to change the system rather than having the responsibility heaped on the shoulders of the individuals making websites.
It’s a fair point. Much like the concept of a personal carbon footprint started life at BP to distract from corporate responsibility, perhaps we’re going to end up navel-gazing into our individual websites when we should be collectively lobbying for real change.
It’s akin to clicktivism—thinking you’re taking action by sharing something on social media, when real action requires hassling your political representative.
I’ve definitely seen some examples of performative sustainability on websites.
For example, at the start of this particular debate at Web Summer Camp we were shown a screenshot of a municipal website that has a toggle. The toggle supposedly enables a low-carbon mode. High resolution images are removed and for some reason the colour scheme goes grayscale. But even if those measures genuinely reduced energy consumption, it’s a bit late to enact them only after the toggle has been activated. Those hi-res images have already been downloaded by then.
Defaults matter. To be truly effective, the toggle needs to work the other way. Start in low-carbon mode, and only download the hi-res images when someone specifically requests them. (Hopefully browsers will implement prefers-reduced-data soon so that we can have our sustainable cake and eat it.)
Likewise I’ve seen statistics bandied about around the energy-savings that could be made if we used dark colour schemes. I’m sure the statistics are correct, but I’d like to see them presented side-by-side with, say, the energy impact of Google Tag Manager or React or any other wasteful dependencies that impact performance invisibly.
That’s the crux. Most of the important work around energy usage on websites is invisible. It’s the work done to not add more images, more JavaScript or more web fonts.
And it’s not just performance. I feel like the more important the work, the more likely it is to be invisible: privacy, security, accessibility …those matter enormously but you can’t see when a website is secure, or accessible, or not tracking you.
I suspect this is why those areas are all frustratingly under-resourced. Why pour time and effort into something you can’t point at?
Now that I think about it, this could explain the rise of web accessibility overlays. If you do the real work of actually making a website accessible, your work will be invisible. But if you slap an overlay on your website, it looks like you’re making a statement about how much you care about accessibility (even though the overlay is total shit and does more harm than good).
I suspect there might be a similar mindset at work when it comes to interface toggles for low-carbon mode. It might make you feel good. It might make you look good. But it’s a poor substitute for making your website carbon-neutral by default.
Styling a list of nested details elements to create a beautiful lokking tree view, all in CSS, all nicely accessible.
It’s been almost two years since I added audio playback on The Session. The interface is quite straightforward. For any tune setting, there’s a button that says “play audio”. When you press that button, audio plays and the button’s text changes to “pause audio.”
By updating the button’s text like this, I’m updating the button’s accessible name. In other situations, where the button text doesn’t change, you can indicate whether a button is active or not by toggling the aria-pressed attribute. I’ve been doing that on the “share” buttons that act as the interface for a progressive disclosure. The label on the button—“share”—doesn’t change when the button is pressed. For that kind of progressive disclosure pattern, the button also has an aria-controls and aria-expanded attribute.
From all the advice I’ve read about button states, you should either update the accessible name or change the aria-pressed attribute, but not both. That would lead to the confusing situation of having a button labelled “pause audio” as having a state of “pressed” when in fact the audio is playing.
That was all fine until I recently added some more functionality to The Session. As well as being able to play back audio, you can now adjust the tempo of the playback speed. The interface element for this is a slider, input type="range".
But this means that the “play audio” button now does two things. It plays the audio, but it also acts as a progressive disclosure control, revealing the tempo slider. The button is simultaneously a push button for playing and pausing music, and a toggle button for showing and hiding another interface element.
So should I be toggling the aria-pressed attribute now, even though the accessible name is changing? Or is it enough to have the relationship defined by aria-controls and the state defined by aria-expanded?
Based on past experience, my gut feeling is that I’m probably using too much ARIA. Maybe it’s an anti-pattern to use both aria-expanded and aria-pressed on a progressive disclosure control.
I’m kind of rubber-ducking here, and now that I’ve written down what I’m thinking, I’m pretty sure I’m going to remove the toggling of aria-pressed in any situation where I’m already toggling aria-expanded.
What I really need to do is enlist the help of actual screen reader users. There are a number of members of The Session who use screen readers. I should get in touch and see if the new functionality makes sense to them.
This is a thoughtful proposal for a browser feature from Bram. Very convincing!
This is a great deep dive into a single component, a password toggle in this case. It shows how assumptions are challenged and different circumstances are considered in order to make it truly resilient.
I added a dark mode to my website a while back. It was a fun thing to do during Indie Web Camp Amsterdam last year.
I tied the colour scheme to the operating system level. If you choose a dark mode in your OS, my website will adjust automatically thanks to the prefers-color-scheme: dark media query.
But I’ve seen notes from a few friends, not about my site specifically, but about how they like having an explicit toggle for dark mode (as well as the media query). Whenever I read those remarks, I’d think “I’m really not sure I’ve got time to deal with adding that kind of toggle to my site.”
But then I realised, “Jeremy, you absolute muffin! You’ve had a theme switcher on your website for almost two decades now!”
Doh! I had forgotten about that theme switcher. It dates back to the early days of CSS. I wanted my site to be a demonstration of how you could apply different styles to the same underlying markup (this was before the CSS Zen Garden came along). Those themes are very dated now, but if you like you can view my site with a Zeldman theme or a sci-fi theme.
To offer a dark-mode theme for my site, all I had to do was take the default stylesheet, pull out the custom properties from the prefers-color-scheme: dark media query, and done. It took less than five minutes.
So if you want to view my site in dark mode, it’s one of the options in the “Customise” dropdown on every page of the website.
Use a toggle switch if you are:
- Applying a system state, not a contextual one
- Presenting binary options, not opposing ones
- Activating a state, not performing an action
When we hide content, there’s a greater risk the user won’t see it. There’s a higher reliance on digital literacy and it’s generally more labour intensive for the user.
Worse still, sometimes we kill off essential content.
This is a really nice write-up of creating an accessible progressive disclosure widget (a show/hide toggle).
Where it gets really interesting is when Andy shows how it could all be encapsulated into a web component with a progressive enhancement mindset
Sara shows a few different approaches to building accessible toggle switches:
Always, always start thinking about the markup and accessibility when building components, regardless of how small or simple they seem.
This ever-growing curated collection of interface patterns on CodePen is a reliable source of inspiration.
I think about 90% of the JavaScript I’ve ever written was some DOM scripting to handle the situation of “when the user triggers an event on this element, do something to this other element.” Toggles, lightboxes, accordions, tabs, tooltips …they’re all basically following the same underlying pattern. So it makes sense to me to see this pattern abstracted into a little library.
The latest edition of Heydon’s Inclusive Components is absolutely fantastic! The pattern itself—toggling sections of content—is quite straightforward, but then there’s a masterclass in how to create a web component that still allows the content to be accessible in older browsers. The key, as ever, is progressive enhancement:
Whether implemented through web components or not, progressive enhancement not only ensures the interface is well-structured and robust. As we’ve seen here, it can also simplify the editorial process. This makes developing the application and its content more inclusive.
A good introduction to variable fonts, and an exploration of the possible interface elements we might use to choose our settings: toggles? knobs? sliders? control pads?
Another great deep dive by Heydon into a single interface pattern. This time it’s the tooltip, and its cousin, the toggletip.
There’s some great accessibility advice in here.
I wrote a little while back about making an accessible progressive disclosure pattern. It’s very basic—just a few ARIA properties and a bit of JavaScript sprinkled onto some basic HTML. The HTML contains a button element that toggles the aria-hidden property on a chunk of markup.
Earlier this week I had a chance to hang out with accessibility experts Derek Featherstone and Devon Persing so I took the opportunity to pepper them with questions about this pattern. My main question was “Should I automatically focus the toggled content?”
Derek’s response was very perceptive. He wanted to know why I was using a button. Good question. When you think about it, what I’m doing is pointing from one element to another. On the web, we point with links.
There are no hard’n’fast rules about this kind of thing, but as Derek put it, it helps to think about whether the action involves controlling something (use a button) or taking the user somewhere (use a link). At first glance, the progressive disclosure pattern seems to be about controlling something—toggling the appearance of another element. But if I’m questioning whether to automatically focus that element, then really I’m asking whether I want to take the user to that place in the document—in other words, linking to it.
I decided to update the markup. Here’s what I had before:
<button aria-controls="content">Reveal</button>
<div id="content"></div>
Here’s what I have now:
<a href="#content" aria-controls="content">Reveal</a>
<div id="content"></div>
The logic in the JavaScript remains exactly the same:
aria-controls attribute (these were buttons, now they’re links).aria-hidden="true" and make that element focusable by adding tabindex="-1".aria-expanded="false" on the associated link (this attribute can be a bit confusing—it doesn’t mean that this element is not expanded; it means the element it controls is not expanded).aria-hidden and aria-expanded when there’s a click event.aria-hidden is set to false on an element (thereby revealing it), focus that element.You can see it in action on CodePen.
See the Pen Accessible toggle (link) by Jeremy Keith (@adactio) on CodePen.
Here’s a bit of convergent evolution: Hugo’s script is similar to what I wrote about recently.
He also raises a point that Kevin mentioned:
I would like to investigate on the
detailsandsummaryelements as they are basically a native implementation for content toggles.
For some reason details never got much browser love, even though it’s clearly paving a well-trodden cowpath.