Archive: October 27th, 2020

Replying to a tweet from @wormmmoon

Can’t beat a good vinaigrette:


Sara tweeted something recently that resonated with me:

Also, Pro Tip: Using ARIA attributes as CSS hooks ensures your component will only look (and/or function) properly if said attributes are used in the HTML, which, in turn, ensures that they will always be added (otherwise, the component will obv. be broken)

Yes! I didn’t mention it when I wrote about accessible interactions but this is my preferred way of hooking up CSS and JavaScript interactions. Here’s old Codepen where you can see it in action:

[aria-hidden='true'] {
  display: none;

In order for the functionality to work for everyone—screen reader users or not—I have to make sure that I’m toggling the value of aria-hidden in my JavaScript.

There’s another advantage to this technique. Generally, ARIA attributes—like aria-hidden—are added by JavaScript at runtime (rather than being hard-coded in the HTML). If something goes wrong with the JavaScript, the aria-hidden value isn’t set to “true”, which means that the CSS never kicks in. So the default state is for content to be displayed. There’s no assumption that the JavaScript has to work in order for the CSS to make sense.

It’s almost as though accessibility and progressive enhancement are connected somehow…

Replying to a tweet from @hankchizljaw

I like the fallback you get with a link (assuming it’s using a valid fragment identifier)—if anything goes screwy with the JavaScript, the link still works.

Replying to a tweet from @hankchizljaw

I’d be interested in getting your take on the logic I’m using here:

…generally you can’t go wrong with a button. … That said, I think that links can also make sense in certain situations.

Eating toast (with marmite).