Eric wrote about how to instruct an LLM to fetch the "valuable stuff" from the ARIA Authoring Practices Guide (APG). The article includes some points about APG itself that are worth highlighting. And what's the valuable stuff?

If you don't know the Authoring Practice Guide, here's what you'll see after finding it online looking for ARIA patterns.

As you see above, the guide is supposed to teach how to use accessibility semantics defined by the Accessible Rich Internet Application (ARIA). And it looks very authoritative. When I first discovered it after some googling, I treated this guide as the source of truth because it lives under w3.org and looks very official. I learned early on that using ARIA correctly is hard; and thought that APG must be the place showing me how to do ARIA correctly.

It sort of is but not really.

Lately, I've seen many accessibility folks raise concerns about APG, and Eric's article echoes some of them.

The APG was created to demonstrate ARIA's capabilities. Because of this, it disproportionately favors ARIA in its code examples.

The guide is there to showcase ARIA usage patterns and if people want to showcase something they might overuse it at times. This is true for ARIA usage in the APG, too.

The APG was also not created to serve as a pattern library, design system, or single source of truth for the "right way" to make something. Unfortunately, a lot of people treat it this way.

I understand Eric's point, but I also can't blame people for treating the guide as "the right way". The home page literally says that "APG provides design patterns and functional examples". It's hosted on w3.org. It looks very official. If there's a line between "a collection of design patterns" and a "pattern library" at all, it's a very thin one.

Of course people treat the Authoring Practice Guide as the right way to do things — when I discovered it, I did, too.

Recall here that the original reason for APG code is to be a showpiece for how ARIA could hypothetically be used. Because of this, it is not the APG's concern that ARIA does not have perfect support.

This is by far the biggest reason why I don't pretend to know when something is truly accessible. Nothing is ever fully accessible to everyone, and the world of assistive technology is huge. A single ARIA attribute might make things more accessible in theory, but who knows if it works across all browser-screen reader combinations.

The effort alone to verify that an ARIA pattern works well across assistive technologies is massive.

But what are the guide's valuable parts? Eric highlights the pattern names, "about this pattern" section and the keyboard interaction specification.

The pattern names. Having a standardized way to refer to a discrete piece of UI that is larger than any one company is highly beneficial.

The content contained in the "About This Pattern" section. This is what the discrete piece of UI does, and how it goes about doing it.

The content contained in the "Keyboard Interaction" section. This is how people who use assistive technology will expect things to work.

That's good to know!

So if you've been treating APG as the definitive source of truth, think again. Its examples demonstrate what ARIA can do, not necessarily what you should do.

It doesn't matter if you've discovered the ARIA Authoring Practices Guide or not, before reaching for a complex ARIA pattern found on the internet, the usual rules apply:

• Always start with native HTML: the first rule of ARIA is to use a native HTML element before adding ARIA. A <button> beats a <div role="button"> every time regardless of what's written in a fancy ARIA guide or what your LLM claims to be accessible.
• Test with assistive technology yourself: nothing beats firing up a screen reader and actually navigating your own UI. It's hard and time-consuming but you can't claim that something is accessible if you haven't tested it.
• Follow practitioners who do the testing: as you might know, I'm a huge fan of Adrian Roselli who constantly puts in the work of testing ARIA patterns with different assistive technology combination. He publishes findings on what actually works versus what the spec promises. Huge!

Edit: Eric (partly responsible for the Authoring Practices Guide) shared on Mastodon how the project evolved into what it is today.

My Mac was running out of disk space the other day, and because I wasn't in the mood to hunt for custom solutions, I reached for Clean My Mac. It's a nice tool, and I knew it would do the job just fine. It freed up 60GB in about twenty minutes. Nice! Cleaning up disk space without any hassle was worth paying for.

A couple of days later, Nick sent out his "One tip a week" newsletter, and dang it... He shared Mole — a free open source CLI tool that does the same thing as Clean My Mac. Too late, Nick. Too late.

I haven't tried it, but I trust Nick's judgment here. You might want to give it a try if you're running low on disk space.

How do you know that you can trust someone?

I struggle to answer this question objectively because trust feels like such a subjective matter. Some people just don't "sit right with me," and that's okay. I also can't expect that I'm trusted and liked by everyone. That's okay, too.

But why is it so hard to explain why you trust someone or not?

Explaining feelings is hard for many, but I just discovered a helpful tool: the trust equation. The formula is like math for feelings — yay!

[Interactive component: visit the article to see it...]

Here's a direct quote from the post explaining what all the variables mean:

Credibility: What we say and the expertise we bring.

Reliability: What we do consistently.

Intimacy: How safe others feel sharing with us.

Self-Orientation: How much we appear to be acting in our own interest (lower is better).

Looking back at my own professional experience, this equation makes a ton of sense.

For me, the biggest kicker is reliability. I've worked with too many people promising the world while constantly failing to deliver. It drives me up the wall that overpromising is "normal" for some folks.

In close second place is self-orientation. I've also worked with the classic solo career climber and backstabber. It was clear that I was working with someone who had an agenda that didn't include me or the team. No fun, no trust.

Credibility and intimacy are also important, but not as important for me as the first two.

However, I guess the formula checks out, and I'll definitely come back to it when I need to evaluate why I don't trust someone.

Here's a quick and handy addition to the Firefox DevTools.

Whenever you debug CSS that's full of CSS variables, it becomes annoyingly hard to parse everything going on in the DevTools because the custom properties are cluttering :root or * or whatever.

Firefox 145 (released Nov 11, 2025) now added a tiny adjustment that helps out massively.

Love it!

Jim is, as always, on point.

My desire to give you constructive feedback is in direct correlation to your effort to care — about your communications, about what you ship, even about what you don't ship.

Shipping something unfinished, half-assed or broken to "gather feedback" just won't do any good. There is a certain (and often obvious) level of quality that needs to be reached before asking for feedback. If laziness shows, nobody will care...

I just stumbled over this package: @pierre/diffs.

@pierre/diffs is an open source diff and code rendering library. It's built on Shiki for syntax highlighting and theming, is super customizable, and comes packed with features.

The package just hit v1 and seems to be pretty new. The docs live on diffs.com (no idea how one could snatch this domain in 2026) and it looks amazing.

It comes as a React and Vanilla JS component, supports server-side rendering, and the configuration options look solid.

Disclaimer: I haven't tried diffs but I can imagine that I will take it as a starter for this blog eventually.

Simon Willison published "Your job is to deliver code you have proven to work".

It frustrates me that the developer community is at a point in which posts like this need to be written, but let me share some highlights.

[Coworkers submitting huge untested PRs is] a dereliction of duty as a software developer.

A dereliction of duty as a software developer...

When I got into tech, nerds were proud to be nerds. People were excited about creating things with nothing but their ideas and a computer. Everyone in my community was excited to put in the work and we all celebrated the results. I loved it!

The pride and excitement in crafting something seems to be vanishing. AI enthusiasts question doing the actual work, and "Can't AI do this?" is one of 2025's most annoying questions.

Where did the pride in doing the work or becoming an expert go?

Tech workers (myself included) had a good run the last 15 years because we cared and built up expertise. Should we now really expect to make the same living with some prose prompting that everyone can learn in a couple of weeks? I really doubt it.

We call ourselves engineers; let's celebrate the craft, be excited about our own ideas, and put in the work to create software.

Your job is to deliver code you have proven to work. [...] Not doing that directly shifts the burden of the actual work to whoever is expected to review our code.

Every reckless AI submission can take someone else hours to deal with. Throwing unreviewed AI Slop onto someone else's table is careless and tells more about you than you think. Don't do it.

If AI did your part in five minutes, it rarely means that the work is done.

A computer can never be held accountable. That's your job as the human in the loop.

Claude won't get fired for your buggy pull request. Just saying...

Here's Remy sharing how to enable template string syntax highlighting via JavaScript comments.

The problem of unhighlighted template strings never really bugged me. I write many of this blog's interactive components without proper syntax highlighting, because I've built myself a custom mini Astro framework. And of course, like many homegrown solutions, it lacks a good developer experience. Missing syntax highlighting was never an issue, though, and things are fine.

However, now that I've read Remy's post, why not make things a little nicer to look at?

Remy describes that when using the right JS comments, Prettier and the VS Code formatter will work together to format and syntax-highlight the template string content.

Unfortunately, that didn't work in VS Code and I had to install two additional VS Code extensions:

• es6-string-css
• es6-string-html

But now I can use /* CSS */ to get some template string CSS highlighting.

And if I use HTML in template strings, it'll be highlighted and even formatted via Prettier.

That's very nice! Thank you Remy for the push!

Disclaimer, I didn't come up with the idea of firing the Raycast confetti from the command line.

Josh's tip is too good not to write down, though, because more people need to know about it. And, obviously, shell sessions need more confetti!

But who's Josh? Josh maintains a public TIL repo that I'm following via RSS. He (and I now) learned how to use the Raycast Confetti command from the CLI.

Implementing the command is almost too easy. Here's my new ~/.bin/confetti command.

#!/bin/bash

open raycast://extensions/raycast/raycast/confetti

That's it!

Apparently, Raycast registers a protocol handler (raycast://) which you can call from anywhere. Whenever you open this URL (your browser works fine, too), the Raycast "confetti" command will be triggered. Magic!

I can't help it but I just love single-purpose URLs. There's for example dontasktoask.com. I love it! Or nohello.net. I love this one, too! And, of course there's shouldiuseacarousel.com. Fabulous!

And now there's a new one in town: stopcitingai.com. To whoever created this: thank you!

I don't agree with everything Pablo writes in It's insulting to read your AI-generated blog post. For example, I think it's fine to use AI for grammar fixes or translations when neeeded.

This opening sentence is a real banger, though!

It seems so rude and careless to make me, a person with thoughts, ideas, humor, contradictions and life experience to read something spit out by the equivalent of a lexical bingo machine because you were too lazy to write it yourself.

It's a shame that the latest AI trend is figuring out how to replace our beloved internet. To state the obvious: the master plan is to make websites invisible to the public and let agents do "the web browsing" for us.

Every AI-focused product tries exactly this on a smaller scale for a while; "Hey you! Do you want to use our slurped-in and almost accurate content summary instead of reading something yourself? It's great (but, remember, use it at your own risk)!".

To scale up, browser makers now try to convince us to use LLMs and AI makers try to build and sell browsers. Web browsing isn't the goal, though, and the direction is pretty clear. AI companies need to reach more people and the old web we know is the obvious target.

Ibrahim struck a nerve in his recent post:

When Chrome browses for me, it will surface what it wants me to see, filtered through corporate priorities, advertising relationships, and engagement metrics. Over time, through a kind of digital Stockholm syndrome, I'll start believing these curated choices reflect my authentic preferences. I'll mistake algorithmic manipulation for personal agency.

Accessing a curated or filtered internet isn't a new problem, though. Search became the first gatekeeper decades ago. If a site isn't on Google Search it might not exist, right? But regardless of whether a site is visible on search or not, it can still be accessed, linked to and discovered. The open web is still out there!

To work around this filter problem, I avoid relying on search or algorithms to discover and consume content as much as possible. My RSS reader and email inbox are always full. Every day, I hear from fellow humans, trusted publications and my favorite bloggers. They'll reach me without a middleman and there's no algorithm or feed that can cut this connection.

But what will happen when LLMs manage all the internet content for us? What will happen when we won't be browsing the web but generated answers? Will all the manipulation we know from social media enter the general web; just on a bigger and much scarier scale?

If LLMs will become the new information gatekeeper, we won't be in charge of our consumed content anymore. If LLMs will curate and summarize the web for the general public, ignored sites might as well not exist and our internet reality might be controlled by software developed in silicon valley.

What could go wrong, right?

I've been using the Polypane frontend development browser for over a year now, and I've always known that I'm not using the tool to its fullest potential.

To solve this problem and improve my frontend workflows, I invited Kilian to show me his favorite tips and tricks.

If you're wondering why you should use Polypane or if you're like me and don't know about all the hidden pro-features, this video is for you!

As someone fearing about the future of web development, I can only say that I hope Jeffrey is right on this one.

As vibe-coded apps and self-creating websites become the norm, luxe companies will pay large dollars for bespoke, hand-crafted HTML and CSS.

It would be great to continue making a living by working in the field we used to call web development...

You might know that I'm still holding on to using Firefox as my daily driver. Things aren't looking great at Mozilla and I'm still peeking at Vivaldi, but so far I simply haven't made the switch.

Now, Kaushik shared some Firefox styling tricks in "How to Firefox" that I didn't apply, but I learned how to fix a behavior that was silently bugging me for 20 years now.

You know when you open a new tab with CMD+T and the new tab always goes to the end of your tab list. For people with a few open tabs this might not be a big deal, but I'm a tab hoarder with 177 open tabs right now. If I'm on tab 50 and decide to open a new tab, chances are pretty high that the new tab is related to the fiftieth tab.

If you want to open tabs next to your current tabs, head over to your about:config and change browser.tabs.insertAfterCurrent and browser.tabs.insertAfterCurrentExceptPinned to true.

That's it! Right now I'm pretty happy with this change. Let's see if it lasts.

Update: I've had this setting turned on for a week and it drives me insane because it doesn't only open new tabs open "inline". New tabs coming from clicking on URLs outside Firefox will also open at the current tab position and this leads messed up tab order.

There are many accessibility audit tools out there. The most mainstream one is probably Chrome's Lighthouse Accessibility audit. But let me tell you a secret.

Accessibility testing isn't done after achieving a green Lighthouse score.

Here's Steve Faulkner listing WCAG success criteria that aren't covered by today's tools.

Some obvious examples:

Automated tools can detect missing alt attributes but cannot determine if alternative text is meaningful.

Tools can check for semantic HTML elements (e.g., headings, lists, tables) but cannot determine if relationships are accurately conveyed.

Tools can analyze DOM order, but manual review is needed to verify if reading order makes sense.

Tools can verify the presence and structure of the title element, but cannot determine whether the title text is meaningful or descriptive.

Tools can detect link text, but manual testing is needed to verify if the link text makes sense in context.

Tools are great for "obvious" technical accessibility but for everything else manual testing is still required.

Here's Simon Willison explaining his approach to link blogging. If you haven't heard of link blogging, it's social media's worst enemy.

Instead of feeding third-party platforms with your thoughts and relying on algorithms for people to discover them, you post links on your corner of the internet (aka your website). The world can then follow your updates via RSS. You might be surprised how much your RSS feed can feel like if you subscribe to enough link blogs.

But what if no one is following or reading along? What value do link posts have in your hidden internet corner?

There's a saying that every written post has a unique perspective. While this sentence holds for blog posts, I have a hard time finding the uniqueness of "Check this out! [link]" posts. Is it worth to put these on my site?

Here's Simon again:

The value is in writing frequently and having something to show for it over time – worthwhile even if you don’t attract much of an audience (or any audience at all).

Yes! "Having something to show" is a blog benefit we need to talk about more often.

From the beginning, blogging helped me build my professional network and get jobs. One of my first blog posts got a bit of traction, and Googlers commented on it. Wild! Occasionally, people tell me that they know me from my blog. #wat?! 😅

But most importantly, I can (and do pretty often) show people this blog. Am I an expert in everything written here? Not at all... But having written about a topic often makes me more of an expert than someone who hasn't.

This blog played a role in most of my job interviews. Noted, I'm working in developer relations these days (writing is somewhat essential in this job), but either way, having a relevant online presence will earn you bonus points.

Because having a blog shows that you care. You care about the internet. You care about a specific topic. You care about sharing knowledge. You're into something.

Of course, running a blog in today's tech world and job market is not required, but having "something to show" is always better than having nothing to show, even if it's "just" a collection of relevant links. Hit publish and show it to the world!

I learned about a new coding style today: the space shuttle.

It's described in the kubernetes source code:

This controller is intentionally written in a very verbose style. You will notice:

1. Every 'if' statement has a matching 'else' (exception: simple error checks for a client API call)
2. Things that may seem obvious are commented explicitly

We call this style 'space shuttle style'. Space shuttle style is meant to ensure that every branch and condition is considered and accounted for - the same way code is written at NASA for applications like the space shuttle.

I love it! Usually I'm not working on projects bringing people to space, but treating critical code with the same care seems like a good idea. 😅

The Sidebar newsletter was one of my primary sources when I started in webdev. Every workday, it shares (or used to share) web design links. It's now taking a break.

The reasons: lack of time, good content becoming less accessible and money.

Let's get to the last point. Sidebar wasn't a small newsletter. 60k people received five emails a week and it was not sustainable anymore. Wow!

Here's Sacha Greif talking about the money part:

Very sad. What many don't see, running a newsletter eats a ton of time.

Let's do some math: in Sidebar's case, we're talking about five weekly emails with a few links. That's quickly done, right?

To make things easy to calculate: let's ignore the content reading and curation part and assume that writing, grammar checking and sending these mails take an hour each.

This makes 5 hours a week, 20 hours a month, or roughly 250 hours a year. If we put an easy-to-calculate hourly rate of $100 next to this time, we end up looking at time worth $500 a week, $2000 a month and $25000 a year.

On top of that, sending over a million monthly emails (20 monthly emails sent to 60k subscribers) isn't cheap either. That's another few hundred dollars a month.

It's neither quickly done nor cheap.

Sacha points out that he failed to get enough sponsors on board. Meaning, he hasn't had time to knock on doors and ask for money. But is he really the one to blame for favoring sharing good stuff over putting ads in front of his readers? This feels off.

Good content is already becoming rare with AI and Search enshittification in full swing. Algorithms promote hate, drama, and "engagement". The state of online content discovery is bad — really bad — and it won't get better soon.

So, what am I getting at here?

We, you and I need to support our local content dealers. Content creators, newsletters and curators are essential for discovering "the good stuff"™.

I'll revisit my content subscriptions and feeds this month to see whom I can support. If you can, you might want to do the same.

Either way, thanks, Sacha, for showing me the web dev and design ropes ten years ago! 💙

Update: Sacha himself has read this post and commented:

Just to be clear I definitely don't blame Sidebar readers for any of this, I'm sure if I had asked for payment or even donations I would've earned enough. It's really mostly about the time and focus.

Disclaimer: I don't have the answer to this hefty post title, but Jacob Kaplan-Moss just woke me up to think about life. So, let's blog about it.

I don't know Jacob, but wow... this is an excellent and very uncomfortable question.

At work, I'm structured, focused and transparent. I have processes and guardrails in place to hit my targets. I reflect, write brag documents, and plan ahead. I hold myself accountable if I don't deliver. Being good at my job is important to me. Being a good colleague is important to me. And somehow, I succeed at all this (most of the time).

But looking into my private life, I've been hunting the same goals for years. Of course, my todo list includes the personal classics: "Eat healthier!", "Meditate!", "Reflect!", "Be kind and calm!". And these items are okay because we all struggle with them, right?

However, the list also includes quick tasks like filing taxes or calling loved family members and friends; I can ignore these for months.

I'd never treat a work task this way, but it's acceptable to ignore the private tasks. For whatever reason, it's fine to deprioritize the things that should matter most. Isn't this weird? Am I weird?

I've no idea why it's like it is or how I can fix my divided personality (does it even need fixing?), but Jacob's question hits home big time this early morning...

Bun 1.1 was released, and of course, "Everything's faster" — again.

Fun fact: the runtime added a native stringWidth method to evaluate character widths on the command line — and, wait for it... it's 6000x times faster than Sindre's string-width. I don't know, but I have a hard time taking these announcements seriously. In Bun, everything's "just faster" — it doesn't matter whether the improvement matters. Let's slap a big number onto it... 🤷

And while I remain skeptical of the new JS runtime, bundler, package manager, [ADD YOUR DESIRED JS TOOLING], and overall JavaScript BFF, I love that Bun's pushing the JS ecosystem.

You know that with npm, whenever you install dependencies, the installed packages can run arbitrary scripts via postinstall? Isn't this wild? And why doesn't the JS ecosystem collapse? Nobody knows.

Bun now tackles this problem with trusted dependencies. Mark packages as trustworthy with bun pm trust, add them to your package.json and be a bit safer when downloading the internet to install your app's dependencies.

{
  "name": "my-app",
  "version": "1.0.0",
  "dependencies": {
    "@biomejs/biome": "1.6.1"
  },
  "trustedDependencies": [
    "@biomejs/biome"
  ]
}

With trusted dependencies, you can define what packages are allowed to run lifecycle scripts when you run bun install. If a package isn't trusted, it can't sniff out your environment variables or mine bitcoins — seems reasonable.

Let's see if there'll be an npm reaction.

How do you evaluate your software's doing what it's supposed to do?

Do you test all your app's possible cases, branches and states? I don't, at least not manually. Nobody aint time to manually click through all the edge cases. QA'ing a simple login form takes time, let alone testing complex applications.

Having robots do that helps a ton, and I recommend writing automated tests to help you sleep well at night (and release fewer bugs)!

Ignoring the burden of writing and maintaining tests, testing a "normal" web application is straightforward because it's predictable. Throw something at your app and expect a result. It should always do the same. Most apps are CRUD apps anyway — easy peasy.

But what if there are unpredictable parts in your app's core?

If you're riding the AI buzzword wave, you probably implemented an "I know everything" smart-ass right in your app's core that's known for lying and spreading fake news. (Yes, I mean some sort of LLM.)

How would you test your app's quality if you're building software on top of software you probably don't understand?

Here's Hamel Husain's recommendation:

There are three levels of evaluation to consider:

• Level 1: Unit Tests
• Level 2: Model & Human Eval (this includes debugging)
• Level 3: A/B testing

I'm not planning to get into serious AI work or LLM programming anytime soon, but unit testing software sitting on top of LLMs is fascinating and worth more than a bookmark!

I'll definitely reference the following blog post in the future. Kitty Giraudel describes when to use disabled and aria-disabled.

Ready? Because here comes some solid HTML attribute advice.

Generally, Kitty shares the following guidelines on when to use which attribute:

1. Use readonly on elements which's values still matter to the user and should be sent to the server.
2. Use disabled on elements which's values became irrelevant for some reason.
3. Use aria-disabled on elements which's interactivity is essential to succeed, because they'll stay focusable and can still trigger validations.

Great great guidelines!

You know the problem: you want to reuse custom properties in media queries but can't.

:root {
  --width: 20em;
}

/* this doesn't work :/ */
@media (min-width: var(--width)) {
}

I discovered the solution to this problem a while ago — custom media queries.

/* this isn't supported anywhere */
@custom-media --narrow-window (max-width: 30em);

@media (--narrow-window) {
  /* narrow window styles */
}

Unfortunately, as far as I know, custom media queries have never been implemented anywhere. Bummer.

However, the CSS evolution is still in full swing, and we have CSS features we couldn't even dream of years ago. :has(), native CSS nesting and container queries are ready to use.

With container queries, custom property style queries are slowly becoming a thing.

MDN Compat Data (source)

Browser support info for Style queries for custom properties

111	111	111	preview*	preview	18	18	22.0	111

* Please check MDN for more details.

Could we use custom properties to formalize variables in media / container queries? Here's Jared White doing just that.

:root {
  --is-mobile: false;

  @media (max-width: 500px) {
    --is-mobile: true;
  }
}

aside.sidebar {
  font-size: 1.5rem;
  line-height: 1.5;
  font-weight: 600;
}

@container style(--is-mobile: true) {
  aside.sidebar {
    font-size: 1.1rem;
    line-height: 1.25;
    font-weight: 500;
  }
}

The style query approach is somewhat different than custom media queries, but it does the job. And if style queries for custom properties ship across browsers, we can call it for custom media queries.

They were a nice idea, but if a media / container query mix allows me to toggle and reuse custom properties based on viewport width, that does the trick for me.

I have the constant urge to "do stuff". My to-do and idea lists are endless collections of things I'd love to do one day. But there's a problem — my side hustle schedule is pretty busy already.

I want to keep this blog active. I run a weekly web development newsletter. I maintain some open-source projects. I collect online tools.

These projects alone eat a good chunk of my free time, and while I love doing them, they add up. There are only so many hours in the day.

For years, I ran the @randomMDN Twitter bot. Then Elmo broke the Twitter APIs. I was puzzled. "This is one of my projects; it can't just be over, can it?" buzzed in my head. I've had a hard time letting go, I guess.

Fast forward. I hadn't had time to fix or deal with the problem, and it was over. Just like that, one of my projects dropped off the list.

I realized I treat most projects as "forever projects".

Of course, I work on this project every week. Of course, I'll answer these GitHub issues over the weekend. Of course, I keep this online resource up-to-date. And, of course, this isn't a sustainable.

As Jamie Wilkinson puts it, he doesn't want to do forever projects anymore. Everything has a shelf life. Kicking things off is great, but letting things go is as important.

It's simple: to have time for new projects and passions, one has to let go.

Great advice.