WCAG-2.2 Subscribe to WCAG-2.2 RSS feed

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.

Where WCAG 3 (3.0) stands in the March 2026 W3C Working Draft: the 12-category, 44-guideline structure, requirement counts, and the return of Bronze/Silver/Gold.

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

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

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

Introduction “We used red and green to distinguish them, so it should be fine.” It’s a thought that comes up naturally during development. But more people than you’d expect have difficulty telling those two colors apart. Statistics based on Northern European ancestry suggest that roughly 1 in 12 men and 1 in 200 women have red-green color vision deficiency. The exact ratio varies by region and genetic background, but the fact remains: there are always users who struggle to distinguish red from green. ...

WCAG 3.0 Draft extends scope beyond web content to wearables, Web of Things, VR/AR, and the tooling ecosystem, and covers how South Korea's kiosk accessibility connects to that expansion.

Introduction Have you ever tried using the internet without a mouse? Most people take their mouse for granted. But there are many people who can’t use one. People with physical disabilities who can’t operate a mouse People with repetitive strain injuries like carpal tunnel syndrome People with temporary arm injuries Power users who simply find keyboards more efficient For these users, the question “Can I use this site with just a keyboard?” is crucial. ...

WCAG 3.0 Assertions document accessibility procedures automated tests cannot verify. This post covers the 28 assertions in the March 2026 Draft and how they differ from WCAG 2.2's Conformance Claim.

Compare WCAG 3.0’s quantitative/qualitative testing flow with WCAG 2.2’s success-criteria model. We cover Atomic/Holistic concepts, view/process scope, and how tests connect to scoring from a practical perspective.