Sometimes a good ol’ list is what we need. I know, I know, this is forever true. But as my friend Dave is wont to say: eliminate nuance. The world doesn’t need nuance on if you should label your inputs by matching the for attribute of the label with the id of the input. You should just do that. Always.

Rauno Freiberg has a terrific list that swipes away nuance: Web Interface Guidelines (also on GitHub). Here’s a few:

Toggles should immediately take effect, not require confirmation

Interactive elements in a vertical or horizontal list should have no dead areas between each element, instead, increase their padding

Gradient text should unset the gradient on ::selection state

Font weights below 400 should not be used

As I read through the list, my well actually finger is so ready to fly up. But no, I shall holster it. After all, the list says guidelines not rules and even if they were taken as rules, the world would probably be better for it for adhering blindly. Break them once you know what you’re doing.

As it often said, accessibility is not a checklist. Butttt a checklist can be helpful for kickstarting things and moving the needle in the right direction.

Forms are an important aspect of accessibility to get right, not to mention a tricky place for UX and security. Speaking of Dave, he’s pretty good lists, and Good forms is one of them. I’ll take just handful of dozens:

Good forms have focus states

Good form elements leverage the inputmode attribute

Good forms validate on the client AND on the server

Good forms should do a pre-flight check for navigator.onLine before attempting a submit

Good forms make the baby Jesus smile

More recently, Dave’s list of Where Web Components Shine is another perfect use of a list.

For progressively enhancing regular ass HTML – Super good at this.

When your components need to exist across different tech stacks – If your company lets departments pick their own tech stack or your company acquires other companies and you need a bit of UI consistency between projects, web components are a great choice.

When you want to make a site without build tools – Build tooling is typically not the starting point for most web component projects.

That last one makes web components pretty CodePen friendly, just sayin.

When are web components not good? There are also plenty of reasons. I’ve dunked on the styling story many times. But here’s another: if you’re building one single web app, you’ll never need to distribute the componentry, and you’re already using a JavaScript framework.

Did you know there are actually four official principles of accessibility? I didn’t but Jeremy Keith laid them out with his takes recently.

I recommend taking a deep breath and focusing on the four principles of accessibility. Together they spell out the cutesy acronym POUR:

1. Perceivable
2. Operable
3. Understandable
4. Robust

I can’t help myself but sneak in a CSS one: Replacing React code with CSS :has selector from Nadia Makrevich. That has a wait, what? feel to the title since React and CSS are quite different bits of technology, but Nadia makes some good points, mostly around where the state logic can go. I’m a big fan of :has() and CSS will almost certainly be a more performant choice. Still, I have to admit that a bit of basic JSX logic can read a little cleaner than a complex CSS selector decoupled from the relevant HTML.

Since we’re talking about lists and I’m essentially writing this on Halloween, I’d like the remind you that this HTML is perfectly fine and valid:

<ul>
  <li>List Item
  <li>List Item
  <li>List Item
</ul>