Posts Subscribe to Posts RSS feed

“Your project spec says ‘must comply with KWCAG 2.2.’ But what does that actually mean you have to do?” If you’ve ever worked on an accessibility project in Korea, you’ve probably paused at a line like that at least once. Search around and you’ll find WCAG mentioned in one place, KWCAG in another, versions 2.1 and 2.2 tangled together — it’s easy to lose track of which standard you’re actually supposed to follow. This post breaks down what KWCAG 2.2 actually is and how it’s structured, from a practitioner’s point of view. ...

Once you’re in the habit of kicking off a long task and walking away, you end up wiring up a notification. And once you have one, the same thought always follows: “This would be nicer on Slack.” Email is quiet and it sticks around, but it’s slow. If you keep Slack open all day, having alerts land in one window you already watch beats digging through your inbox. If you want your phone to buzz the instant something finishes, Telegram is faster. It’s not just a matter of taste, either — if your team already lives in a channel, that’s where the notification belongs. ...

Ever sent off a long task, gone to do something else, and come back to the terminal an hour later only to find it finished thirty minutes earlier? Or the opposite — checking the window every five minutes and getting nothing else done? For me there was one more wrinkle on top of that: when the task produces a file. A markdown writeup of some research, an extracted CSV, a report I asked for. If it finished while I was away, there was no good way to check it from my phone. SSH in and cat the file, and every line break is mangled, you’re scrolling with your thumb, and if there’s a table in there, forget reading it at all. ...

Ever opened someone else’s repository after a while and found a bunch of unfamiliar files sitting there? Next to README.md there’s a CLAUDE.md, an AGENTS.md shows up too, and some repos even have a DESIGN.md. They’re all .md files, but what are they actually for? They’re all documents written to be read by AI — not by people. Just a few years ago, the only markdown files in a repository were the README and maybe a license. But now that AI coding tools have become part of everyday work, projects need to tell AI, too, “here’s how we do things around here.” Instead of repeating the same explanation in chat every time, teams started writing it down in files. That’s how we ended up with the files you’re looking at now. ...

Have you ever asked an AI to “put this in a table” and gotten back text littered with pipes (|) and dashes (-)? It looked like a clean table right there in the chat window — but the moment you copied it into a messaging app, it turned into a mess of symbols. Those symbols are Markdown. These days you run into it everywhere — GitHub READMEs, technical blogs, note-taking apps like Notion, even the replies an AI chatbot sends you. ...

Opening: treating scroll as “time” When you build scroll-based animations, you eventually hit this thought: “What if scroll were not just an input event” “but a proper timeline?” Scroll-Driven Animation is that idea made explicit. Instead of treating scroll as a trigger, you treat it as the timeline itself. In this post, I group implementation strategies into three families: Native CSS Scroll-Driven Animation IntersectionObserver for state changes scroll + requestAnimationFrame with manual progress mapping For each one, we will cover the principle, strengths, tradeoffs, and accessibility concerns. The code samples here are minimal and correct by themselves, and each section ends with a link to a live demo you can poke at directly. ...

This is Part 22 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary What do you end up with when you stack tests onto one small app, one layer at a time? This article is the retrospective on that journey — and a map of frontend testing as a whole. The layers we stacked were these: unit tests that check whether a single function does its one job, component tests that poke at the screen the way a user would, real-browser E2E that sweeps end to end, accessibility checks that protect users who never look at the screen, and CI that runs all of it for you on every PR. By the end, we’d even gotten to verifying code and tests written by AI. ...

This is Part 21 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary AI-written code is fast, it runs, and the screen looks good. The problem is that it’s wrong in plausible ways. Two spots go empty especially often. One is accessibility — the things people who use the web without looking at a screen need. The other is what happens in moments that rarely come up — an empty search box submitted, a server returning a 500. We call these edge cases. Both fall into “nobody covers it unless you ask” territory. ...

This is Part 20 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary By now, AI “writing” test code for you feels familiar. Lately, though, it’s gone a step further — AI has started opening the browser itself, clicking through it, and checking whether things work. It’s a neat trick, but ask “so can I actually use this at work?” and the answer gets fuzzy fast. Tool names keep popping up, but there’s rarely a single piece that lays out what each one actually does and how far you can trust it. This article is that map. ...

This is Part 19 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary Can you just ask AI (large language models like ChatGPT and Claude) to write your tests? Yes. Just don’t trust them as-is. AI produces plausible tests in seconds, but tends to quietly skip the boundary, failure, and accessibility cases that matter most. This article is about employing AI properly as a test-writing assistant — from getting good drafts to the checklist that proves the tests actually work. ...