Web-Accessibility Subscribe to Web-Accessibility RSS feed

You built a modal. You press Tab, and the buttons in the background get focus. You press ESC, and nothing closes. A screen reader plows through the content without even saying “dialog.” And when you click the close button, focus vanishes into thin air. Anyone who builds modals runs into all four of these at some point. The name focus trap sounds great, but the problem is that the trap tends to get set in the wrong place. Let’s fix them one by one. ...

Not long ago I received a trend summary titled “The Spread of AI-Based Accessibility Standards.” Its first line said “W3C’s ARIA-AI Framework discussions are underway.” I went looking, and there’s no such standard. The only places that name appeared were auto-generated posts without a single W3C link. AI and accessibility really have come together, though. Not in standards, though. In tools. OpenAI’s developer FAQ for its AI browser, ChatGPT Atlas, says: “Making your website more accessible helps ChatGPT Agent in Atlas understand it better.” ...

Not many people go back and recalculate the numbers in a report. I didn’t either. When I wrote up the WebAIM Million 2026 report this past July, I copied one line straight into the post: “average of 1,437 elements per home page, up 22.5% in a single year.” Then, while researching a follow-up post, I looked up last year’s figure: 1,257. Going from 1,257 to 1,437 is 14.3%, not 22.5%. I asked WebAIM, and they confirmed it was a calculation error and corrected the original text. ...

I was building a signup form. The moment I focused the email field, an error popped up: “Invalid email format.” I hadn’t typed a single character yet. The password confirmation field was the opposite. I typed the whole password, submitted the form, and only then did it say “Passwords don’t match” — after I’d already finished typing. Then I hit submit, and seven error messages showed up all at once. ...

I’d been happily shipping a React SPA for a while when an accessibility audit came back with this note: “The page changed, but the screen reader said nothing.” The page transition animated smoothly, the URL updated, the content changed… but as far as a screen reader user was concerned, nothing happened at all. That’s the hidden trap of SPAs. Traditional Websites vs. SPAs What happens when you click a link on a traditional multi-page site? ...

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

How do screen readers handle aria-live status messages? A demo-driven look at WCAG 4.1.3, polite vs. assertive, debounce timers, and icon or sound status.

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

A code-first, try-it-yourself rundown of WCAG 2.2's 6 most-used new success criteria, plus the 3 AAA criteria and how KWCAG 2.2 and global standards stack up.