Hi there 👋

“Can we actually say our service is accessible?” Is it done when the checker reports zero errors? If a service has hundreds of screens, do you have to scan them all — or is checking a few enough? And if you pick a few, which screens, how many, and on what grounds can you claim “we comply”? A hand ticking checkboxes one by one on a tablet screen - accessibility evaluation is a matter of following a procedure, not intuition Photo: Jakub Żerdzicki / Unsplash When you study accessibility, there is plenty of material about the standard (WCAG), but surprisingly little about this “how do we evaluate” question. As it turns out, the W3C has had an official answer all along. And on July 23, 2026, that document got its first new version in twelve years: WCAG Evaluation Methodology (WCAG-EM) 2.0. ...

There’s a moment when you’re idly scrolling a running service’s logs and your hand stops. That day, I hit that moment in the audit logs of A11y Check, a web accessibility auditing service. Two audits had been stuck “scanning” for hours. Not in progress, not failed — just stuck. This is what people call a zombie task: a job left in the queue, neither dead nor alive. This is the story of catching those two zombies, of two fixes I was sure of missing, and of finding the real cause only on the third try. To skip to the end: the culprit wasn’t my logic but Vercel’s Deployment Protection — or more precisely, my internal-call code that didn’t account for it. ...

“We’re certified, so we should be fine.” It’s an easy thing to believe on the side that builds the website. Yet even on sites with a certification mark, it’s common for a screen reader user to fail to find the log-in button, or a low-vision user to be unable to read gray text on gray. Having been audited once, and being usable right now, are two different stories. The tool I built to shrink that gap is A11y Check. Put in a URL and it audits the accessibility automatically, then hands back a report and a fix guide. This article covers what A11y Check does, how it works, and why I opened the code. Let’s start with where it came from. ...

This is Part 14 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary “Works on my machine, red on CI.” The homework of everyone who operates E2E, and the prime cause of console.log wallpaper. Playwright ships three tools that solve this mystery with evidence: traces that rewind the failure whole, a UI mode that time-travels, and retries used as a signal. We pack all three today. Series readers: this is insurance for the day your E2E breaks. Searchers: this is the emergency kit for the test that’s broken right now. Examples are self-contained. ...

This is Part 13 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary Past ten E2E tests, two things start to hurt: the setup code copy-pasted into every test, and the suite slowing down as it runs in sequence. Playwright’s fixtures (a mechanism that injects repeated setup into tests) and parallel execution solve both at once — this article covers custom fixtures, auth reuse (storageState), and the safety rules for parallelism. ...

I had clearly written a dark gray into my CSS. color: #595959. On a white background that color has a contrast of 6.4:1, which comfortably clears the accessibility bar of 4.5:1. Pass. Then I ran an accessibility checker, and a red line appeared. This text has a contrast of 4.04:1, which is insufficient. Expected ratio: 4.5:1. I put in a color that measures 6.4:1, so why is it calling it 4:1? Was the checker wrong? ...

This is Part 12 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary Flaky tests — the code hasn’t changed, yet some days it passes and some days it fails. It’s the first illness every team catches when adopting E2E, and left untreated it breeds a scary culture: “that one again? just rerun it.” Fortunately the cause is usually singular: finding elements too early, or the wrong way. This article pulls that root out with Playwright’s locators and auto-wait. ...

Some people set their screen to maximum contrast. Yellow text on black, white text on blue, that sort of thing. For low-vision users this is the difference between being able to read the text and not; people with migraines or light sensitivity go the other way, using a muted, low-contrast palette. They have one thing in common — the user decides the colors. And the moment they do, a good chunk of the colors we wrote in CSS get ignored. ...

I turned on dark mode and my eyes hurt more. The background was black but the text was a heavy gray, so the contrast was far too low; links were still the default blue (#0000ff), which stung. Images blazed alone against the dark screen. One button was the same color as its background, so it was simply invisible. It said “dark mode supported.” But it was dark mode by color inversion, nothing more. ...

This is Part 11 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary Playwright is an E2E testing tool that drives real browsers (Chromium, Firefox, WebKit) with code. E2E (End-to-End) is exactly what it says — reproducing the entire flow of a user visiting, searching, and seeing results, in an actual browser. This article goes from install to a passing first scenario in one sitting. If you’ve been following the series, this is where the stage gets bigger — we’ve been playing inside jsdom, a pretend browser; now we open a real one. New here? No problem: we start from installation, and you can put any Vite/React app of yours where the demo app sits. (Demo UI strings are Korean — 대시보드 = “Dashboard”, 검색 = “Search”.) ...