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 — and only then does someone discover that the thing cannot be operated with a keyboard, or that it has no way to expose a name to a screen reader.

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 people with disabilities while it is still a draft — when 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 visualisation 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 (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 and barely addressed by guidance written for static documents.
• A WCAG Content API (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 people with disabilities as AI content creators (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, and the recent queue has included digital credential specifications, media registries, and machinery for how credentials get rendered and presented — 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. There is a weekly call where the group works through what is in flight, and the wider group also authorises 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 practitioners hit the same friction in the same specification and it never becomes an issue anyone files, because the path from "this was hard to build accessibly" to "the spec should say something" is invisible to most people who could usefully walk it.

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