Development Subscribe to Development RSS feed

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. ...

When we’re deciding whether to adopt a new feature, we usually look at a support table. We check caniuse, see what percentage of cells are green, and once it clears 90%, we think “okay, we can use this now.” But there’s a question the support table never answers: Can you use it with a keyboard? Does a screen reader read it correctly? Those are two different questions. There’s a bigger gap than you’d expect between a browser implementing a feature and that feature actually handling accessibility. Some features quietly replace accessibility code we used to hand-write; others open up brand-new traps. ...

This is Part 18 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary Open a coverage report and four numbers stare back — Stmts, Branch, Funcs, Lines. Which one matters? This article is about reading that report: which number is honest (spoiler: branch), what to fill in from the red lines, and where to look for the team health that numbers can’t show. If you’ve been following the series, this is the hands-on follow-up to the strategy part’s point that “coverage is a reference, not a target.” First time here from a search? That’s fine too — we use Vitest, but reading a report works the same no matter which tool you’re on. ...

This is Part 17 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary Tests have no power while they’re “something you run locally, sometimes.” They protect a team only once they become a checkpoint that runs on every PR. This article builds that checkpoint with GitHub Actions — a merge gate where unit tests, E2E, and accessibility checks must pass before code can merge — from a single workflow file. Never touched CI? Fine. Three minutes of vocabulary first. ...

AI regulation news usually sounds like someone else’s problem. Banned use cases, fines as a percentage of revenue — that reads like legal’s department, not ours. But a provision that takes effect on August 2 contains this sentence: Ensure that high-risk AI systems comply with the accessibility requirements in accordance with Directives (EU) 2016/2102 and (EU) 2019/882 Those two directives are the Web Accessibility Directive and the European Accessibility Act (EAA). In other words, an AI regulation has pulled accessibility standards into itself. Whether you’re building an AI system or deploying one, once it’s classified as high-risk, accessibility stops being “nice to have” and becomes a conformity assessment item. ...

This is Part 16 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary Ever had every test green while the screen was broken? Logic fine, one CSS rule collapsing the layout? Visual regression testing stores a reference screenshot (the baseline) and compares pixels, automatically catching “regressions only eyes can see.” It’s built into Playwright — one line to start — but there’s a knack to stable shots and an ambush called environment differences. All covered here. ...

What happens when you run one million home pages through an automated accessibility checker? About 56 million accessibility errors come pouring out. That’s an average of 56.1 per page. The number alone might get a shrug — “that’s just the web.” The problem is the direction. Last year it was 51. In a single year, errors grew by 10.1%. After years of slow-but-steady progress, web accessibility just took a step backward. ...

Say you run an accessibility checker. You feed it a site’s URL, and the checker has to decide: which pages should it actually look at? Is the homepage enough? If so, you don’t have much basis for saying “this site is accessible” or “this site isn’t.” But checking every page isn’t realistic either — forums, blogs, and shopping sites can have hundreds or thousands of posts. Auditing all of them blows the time and cost budget. ...