Web-Accessibility Subscribe to Web-Accessibility RSS feed

On September 1st, the Claude Code v2.1.257 release notes carried one short line: the default model for the Fable line had switched to 5.1. If you use Fable and have never touched the model setting, the brain writing your code got quietly swapped out that day. The same release notes had an exception, too — the fable alias in Claude app gateway sessions stays on Fable 5 for now. Read this as a story about the regular Claude Code you run from the terminal. ...

Click “Add to Cart” on an online store, and the badge in the top-right corner flips from 3 to 4. For someone who can see the screen, that’s feedback enough. But what about someone browsing the web with a screen reader — software that reads the screen aloud? A number quietly changing somewhere on the page tells them nothing. Whether the item was added, how many are in the cart now, whether it failed — there’s no way to know. ...

A green toast reading “Saved” pops up in the bottom-right corner of the screen. It disappears two seconds later. For someone using a mouse, that’s complete feedback. But for someone who isn’t looking at the screen? That toast never happened. There’s no way to know whether the save succeeded or not. This is exactly what live regions exist to solve. Mark a region ahead of time as one whose content can change without a page refresh, and when the text inside it changes, the screen reader reads it out automatically. One line — aria-live="polite" — is all it takes. ...

If you’ve ever run an accessibility checker, you’ve probably seen a line somewhere in the results like, “This result was verified on a specific browser and screen reader combination.” Every accessibility evaluation starts from some baseline environment. But what exactly counts as that “baseline environment” is something standards documents have rarely defined with any precision. The March 2026 Working Draft of WCAG 3 (3.0) puts a name to this gap — the accessibility-support set — and structures it into a formal clause (§3.2.2). The term itself existed in earlier drafts too; what this draft adds is splitting it into a default set and an alternative set, numbering the clause, and giving it a proper place within the conformance requirements. Read the definition closely, though, and you’ll find a line stating that the baseline is oriented toward English content. This post walks through exactly what that clause says, and what it means for local assistive technology environments like Sense Reader (센스리더), Korea’s dominant local screen reader. ...

“I’ve looked at WCAG 2.1, but what’s new in 2.2?” I get this question a lot doing frontend work. WCAG 2.2 became a W3C Recommendation on October 5, 2023, so it’s been nearly three years now. For reference, the document currently posted at w3.org/TR/WCAG22/ is a December 12, 2024 revised recommendation — the success criteria themselves haven’t changed, it’s just a republication with post-finalization corrections folded in. Yet plenty of teams are still running their checklists against 2.1. It’s not that they don’t know the new criteria exist — it’s more that “nine new ones, do we really have to look at all of them?” has kept it on the back burner. ...

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

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

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