W3C: reviewing standards before they harden

Most accessibility work happens far too late. A specification is written, browsers implement it, frameworks wrap it, products ship on it. Only then does someone discover that the thing cannot be operated with a keyboard, or that it has no way to tell a screen reader its name.

By that point the cost of fixing it is measured in years.

The Accessible Platform Architectures Working Group sits at the other end of that pipeline. When a W3C group proposes a new specification, APA reviews it for its effect on disabled people while it is still a draft. At that stage, changing the answer costs a conversation rather than a decade of legacy.

I joined as an Invited Expert on 18 December 2025, though the involvement started a long way before that. My first comment on an ARIA specification issue was in 2019, on the proposal for a data visualization module, and I have been arguing in those threads on and off ever since.

Three of those arguments were mine to make:

• Using aria-owns with late-mounted descendants (opens in a new tab) (ARIA Practices, 2023) — what authoring guidance should say when the element you need to reference does not exist yet, which is the normal condition in a component framework. Guidance written for static documents barely addresses it.
• A WCAG Content API (opens in a new tab) (WCAG 3, 2024) — success criteria are published for people to read, which makes them hard for tooling to consume reliably. The argument for machine-readable criteria is the same one I now make about design systems.
• Include disabled people as AI content creators (opens in a new tab) (AI Accessibility, 2026) — accessibility discussion about AI almost always casts disabled people as consumers of generated output. They also make things with these tools, and that half is largely missing.

What the work actually is

A queue. Groups across W3C file review requests. The recent ones have included digital credential specifications, media registries, and the machinery for how credentials get rendered and presented. That is exactly the sort of infrastructure that quietly decides, years later, whether somebody can prove who they are without sighted help.

Reviewers get assigned to specifications, read them against what assistive technology can actually do, and raise the gaps as issues on the spec itself. A weekly call works through what is in flight. The wider group also authorizes research notes; an analysis of gaming accessibility is in progress as I write this.

It is unglamorous, and the feedback loop is measured in years rather than sprints. That is the point. A guideline everyone follows was once a draft nobody read carefully.

Why I do this alongside product work

The two halves feed each other, and I did not fully expect that.

The specifications I read at W3C become the constraints I design against at work — usually eighteen months to five years later. Reading them early means I am not learning a standard when a customer's procurement questionnaire forces me to. It also means that when I write an accessibility standard into a repository for my own team, I am writing it from the reasoning behind the criteria rather than from a summary of them.

Going the other way, building products keeps the review honest. It is easy, in a standards conversation, to argue for a requirement that is theoretically correct and practically unimplementable. Having shipped the thing tends to cure that.

Where this goes

I want the traffic between the two to get heavier, not lighter.

The gap I keep noticing is that almost nothing flows back from product teams into standards work. Thousands of us hit the same friction in the same specification, and it never becomes an issue anyone files. The path from "this was hard to build accessibly" to "the spec should say something" is invisible to most of us who could usefully walk it.

I would like to be one of the people who shortens that path. At product level, our accessibility standard lives in the repository, where both people and agents read it before anything is generated. I want to bring that into how teams consume standards in the first place.