Guide Subscribe to Guide RSS feed

Introduction Standards documents change quietly. One morning an email titled “For Review” shows up in your inbox, and when you open the link, the document you read last time has a different structure. On September 10, 2026, the W3C Web Accessibility Initiative (WAI) published a new WCAG 3 (3.0) Working Draft and sent out a call for review comments. A red pen resting beside the fanned-out pages of an open book - standards drafts get revised this quietly, and this often Photo: Emmanuel Phaeton / Unsplash This post is a direct comparison between that September draft and its immediate predecessor, the March 3, 2026 draft. I covered the March draft in WCAG 3 Status Check: A Complete Rundown of the March 2026 Draft — and one of that post’s key sections just got flipped on its head. ...

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

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

“Once WCAG 3 ships, what happens to the KWCAG we’re following right now?” That’s the question I get most often since publishing our complete KWCAG 2.2 guide. “WCAG 3” has started coming up often enough in accessibility newsletters and conference talks that it’s only natural to wonder how KWCAG, our domestic standard, should respond to this shift. Short answer up front: the two standards are moving at different speeds right now, and there’s no need to relearn KWCAG anytime soon. That said, a fairly significant structural shift is on the horizon, so it’s worth knowing the general direction if you work in this space. This post walks through what’s different between the two standards and why that difference matters. ...

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

“Our site needs accessibility certification — where do we even start?” That’s usually the first overwhelming question once this lands on your desk. Running a scanner and clearing every error it flags doesn’t get you certified, and the guidance out there is scattered across too many places. This post exists to cut through that confusion — walking through what certification actually verifies, what standard it’s judged against, and where the pass line sits, aimed squarely at someone preparing for it for the first time. ...

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

↻ 2026-09-10 Updated A new Working Draft was published on September 10, 2026, and it changes the premise of the “Bronze/Silver/Gold Are Back” section below. The September draft defines a single conformance line (all core requirements met) and moves Bronze/Silver/Gold out of conformance into reporting tiers. The requirement count also grew from 182 to 216. This post stays as a record of the March draft; the changes are covered in What Changed in the WCAG 3 September 2026 Draft. Introduction Search for “WCAG 3” and articles describing the 2021 draft still show up near the top — the era of scoring criteria and tallying them into a grade, a concept that has completely disappeared from the document by now. Web standard drafts change fairly often, and there’s less material out there keeping up with the pace than you’d expect. ...

Introduction This is the seventh post in the WCAG 3.0 series. The expanded scope post looked at how far WCAG 3.0 reaches “beyond the web.” This time, I want to answer a question a lot of people keep asking me. “Should we migrate to WCAG 3.0?” Short answer up front: not yet. But there’s an important nuance to that answer. “Conformance” and “improvement” are two different conversations. Source document: This post is based on the W3C Working Draft of March 3, 2026. Drafts are generally updated on a roughly six-month cycle, so details may have shifted by the time you’re reading this. ...

Introduction “How hard can a signup form be?” If that thought has ever crossed your mind… you’ve probably never tested it for accessibility. Forms are the most important interface for user input on the web. Login, checkout, search, surveys — virtually every core web function goes through a form. Yet for countless people, these forms are a complete barrier. Screen reader users can’t tell what an input field is asking for Keyboard-only users get stuck in front of a date picker People with cognitive disabilities see an error message but have no idea how to fix it A web form with multiple input fields — easy to get lost in, just like people navigating a maze. Photo: Susan Q Yin / Unsplash In this post, we’ll go through form accessibility from top to bottom, based on WCAG 2.2. No dry theory — just practical code you can use right away, paired with a demo page I built for this post. ...