[Robin]: There’s a bit of drama in the accessibility world at the moment that’s worth taking a look at. It all hinges around a working draft of the WCAG 3. Here’s the gist: the Web Content Accessibility Guidelines (WCAG) are rules that tell us web developers how to make our websites accessible and it covers a ton of things, like how to use color in our interfaces:
Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
Lots of guidelines are like that. But! They’re not just here to boss us around—even if WCAG compliance is written into law in some cases. The ultimate goal here is to help us make better websites and the WCAG 2.1 (which is the current standard and recommendation) does just that. It provides us with ways to test our work, like with color.
Stacie Arellano wrote about all this a while back and how these color recommendations let us test to see if our websites are easy to read (think black text on white background good, yellow text on yellow background bad). The WCAG 2.1 has rules about how color ratios are calculated, like over on accessible-colors.com where they tell you if your text is readable and what you need to do to fix it.
These ratios in other tools like this one are directly from the WCAG 2.1 guidelines and tons of designers and developers use them to make the case to change the colors of things.
Onto the drama: the new WCAG 3.0 Working Draft has a new color contrast method called Advanced Perceptual Contrast Algorithm (woof!) which looks like it has a much improved method to figure out if our text is readable or not. That’s great! But Eric Eggert argues that WCAG 3 is not ready yet, and it won’t be for quite some time:
In general, web technologies are very good citizens to early adopters like me: They usually come with suitable fallbacks that allow you to use, for example, animations and transitions in 2009 with the fallback of no animation for browsers without support.
With guidelines like WCAG 2.1 and 2.2 (to be released later), the same approach is true. If you use WCAG 2.2 Success Criteria now, the Guidelines are built to be backwards compatible. So you will never break a 2.0 or 2.1 audit by using it. But WCAG 3 breaks backwards compatibility. This is a conscious move to better adapt the standard to serve different disabilities which WCAG 2 did not sufficiently cover, due to its structure.
Interesting! I hadn’t heard about any of this before and it looks like all of this works very differently to CSS or HTML or JavaScript where we’re encouraged to use the latest and greatest tools with progressive enhancement in mind.
Kilian Valkhof clarifies this argument really well here:
Whatever is currently written down as WCAG3, including APCA, is subject to change. This is great! It means developers still have a chance to submit feedback. If you like something, don’t like something, or have suggestions: now is the time.
It also means that whatever is written down as WCAG3 at the moment, is not something you should base your accessibility choices on. Worse, using these guidelines while they’re not ready might lead to you thinking you’re doing the right thing while not conforming to WCAG2, and you’ll have to change it.
So: don’t use APCA, and stick to the current WCAG 2.1 Guidelines when it comes to color. Got it. But I think there’s an important lesson from all this somewhat complicated terminology and drama. I think this proves we shouldn’t jump on the coolest, latest trend when it comes to accessibility because, on the web, accessibility is one of the slowest things to change. And there’s a good reason for that!
If we use the latest stuff too soon then it does the exact opposite of what accessibility best practices attempt to do in the first place and it leaves people behind. So let’s stick to the boring stuff.
3D transforms are neat as heck
I sometimes forget how handy CSS transforms are and how much they can improve a website. Here’s one example from Rob Weychert where he made a fabulous list of horror movies that he planned to watch this year. Look at this fake VHS tape on the right:
It’s a simple enough effect, but stuff like this has a big impact on how the whole website feels. Oh and this reminds me of David DeSandro’s intro to CSS 3D Transforms from a while back where he showed just how bonkers all this can get:
How does !important work with CSS custom properties?
This is certainly news to me: I hadn’t ever thought about how !important is applied to CSS custom properties, like this:
div {
--color: red !important;
color: var(--color);
color: yellow;
}What color does this div end up being here? (Spoilers: it’s yellow!) Stefan Judis wrote about this interesting problem and showed how that div above ignores the !important in the --color custom property but is overridden by the color: yellow; bit.
The point here is that when !important is used in a custom property it only applies to that variable itself. Here’s another example that explains this, look closely this time:
div {
--color: red !important;
--color: yellow;
color: var(--color);
}Now the color of the div above will be red. !important overrides yellow even though it’s defined beneath red, just like how regular CSS works. The change is only scoped to the property.
But again, you can easily override this with another color property like this:
div {
--color: red !important;
--color: yellow;
color: var(--color);
}
.blue {
color: blue;
}In this case the div would be blue. Which makes sense to me! So, if you use !important it only applies to the variable, not the CSS property itself. I’m saying that too many times huh? OKAY WELL I THOUGHT IT WAS NEAT GIVE ME A BREAK, PAL. Jeez.
What’s one thing people can do to make their website better?
Jenn Lukas says maybe nothing:
Our websites keep getting bigger and bigger! When we have a team with so many exciting ideas and such interesting technology, it can be easy to get swept up and not as easy to prioritize all those ideas.
However, there are only so many hours in a day, only so many resources, and only so much our visitors want in an interface without their focus being lost. How do we balance it all?
I’ve found myself on lots of teams where things start to spiral a bit. What if we build this thing and what if we build that other thing? It’s sometimes difficult to figure out if all these conversations and tiny improvements we want to make are actually useful.
Jenn continues:
What happens if we don’t add this animation right now? The close experience might be a bit jarring for our customers without an animation, but maybe not? Will it change conversion? Will it make our readers not come back to our site? Probably not. Let’s keep our priority hats on and move this to our non-urgent/non-important column and revisit someday if we have the bandwidth.
I struggle with this kind of decision-making because I believe that every tiny detail matters. Every animation, every bit of copywriting, every icon. Ultimately we could say “no” to everything and then… our websites would be kind of naff!
But the other day I was in a conversation and we started talking about the spacing of all the components on a website. And oh boy it was a long conversation. How should we go about aligning things properly and consistently? After a good fifteen minutes, I realized that the information on this page didn’t make any sense whatsoever. In fact, the data was mostly useless! We were arguing about something trivial—spacing—when the content on the page was just nonsense and provided no value to the user whatsoever.
So I think Jenn highlights a problem that I notice over and over again, especially on design systems teams. It’s all too easy to focus on the smallest details and obsess over them; the border-radius, the animations, etc., whilst we ignore the most important problems that need to be solved right away.
So: yes. All the details matter, but it’s important to remember that some matter more than most.
Defensive CSS
Okay, this is great. Ahmad Shadeed wrote this enormous post about defensive CSS which are tips to prevent some of the most common problems you’ll encounter when working on a website. Take this one, for example about using flexbox:
A general rule of thumb when using flexbox is to allow wrapping unless you want a scrolling wrapper. That’s another thing, but try to use flex-wrap to avoid unexpected layout behaviors (horizontal scrolling, in our case).
So Ahmad suggests we always write the following:
.options-list {
display: flex;
flex-wrap: wrap;
}Which ends up looking like this:
There’s tons of defensive tricks in this post and I want to list them all out because I bump into these common problems all the time. What’s the pattern though? Well, I reckon they’re mostly caused by me forgetting about how text can either get really long or really small, depending on the context. It’s all too easy to make a component, check it at one size and in one browser and then forget about the multitude of options. And then add a CMS in the mix? Things get real complicated then.
Sponsor
Hashnode
Hashnode is a free blogging platform for developers who want to plug into the global dev community. Own what you create on your own custom domain without the hassle of building it all from scratch, and we’ll connect you with your future biggest fans.
Sponsor
Jetpack Backups: Now Always Realtime
Until now, Jetpack has offered daily backups as an option for site owners. And while this is a great step to protect your site, Jetpack’s real-time backups are the best way to get complete peace of mind. They save a copy of your site each and every time a change is made — a page is updated, a post is added, a setting is tweaked, or a product is purchased — all behind the scenes without requiring you to lift a finger. That way, you know that you’ll never lose a second of your hard work or a single customer order.
That’s why Jetpack is now including real-time backups in each of our Backup and Security plans.
[Chris]: The grand tradition in tech is questioning what came before and building something new to better it. Nothing is off limits. On a small scale, consider CSS resets. Perhaps the first was from back in 2004 and pretty much every year since then someone has tried to throw their hat in the ring and redo the ultimate CSS reset, some more successful than others. This year, two major takes so far: one from Elad Shechter and another from Josh Comeau. It’s interesting to watch them evolve, in no small part because browsers themselves evolve. Sometimes making past choices unnecessary, and sometimes because new technology becomes available that can be used.
I find it interesting when long-standing best practices are questioned as well. For instance, it’s largely gospel that you don’t check in your “built” files when using a Static Site Generator to your Git repository. It causes a lot of git history noise, uses extra bandwidth, etc. Might as well let your host or test runner or whatever run the same build you would locally, right? Same goes for node_modules too. That directory can have many thousands of files init, why would you commit that? Industry-wide, it’s just assumed that we don’t. But Jack Franklin makes the case that… maybe we should. And there are some strong points in there! I doubt it will change the industry overnight, but I like that he’s questioning a best practice and finding bit of value. Like Jeremy did saying maybe we shouldn’t allow third-party JavaScript… at all. Or updating cache headers to better reflect what is actually happening on the web these days.
On a larger scale, maybe this is what “Web 3” is. I don’t think anybody even really agrees on what Web 3 means (or even how to spell it: web3? Web3? Web 3? Web 3.0?) although most attempts have a power-to-the-people vibe. My favorite sentiments around Web 3 revolve around the fact that it questions everything about the web we have today. Much of it feels silly and dangerous to me, like if updates to a website are made via blockchain, can we never truly erase something from being publicly available from the web? Doesn’t that seem highly abusable? But the part I like is questioning everything, right down to the foundations, because it’s that grand tradition that makes tech better.
