When is a standard still cheap to change?

A bricklayer can move a brick for about ninety minutes. After that the mortar has set, and moving it means breaking something.

I keep thinking web platform features work the same way. There's a window (sometimes months, often longer) where a specification is a draft with soft edges, and a well-argued comment can change it.

Once it ships into browsers and into a million pages, the same change costs a decade and a migration guide.

Inaccessible defaults rarely come from a product team. By the time a design team is arguing about a component, most of its behavior was decided years earlier and much further upstream.

That was in a specification, written by people solving a different problem, with accessibility as one concern among many.

I don't read that as a failure of care. Specification work is difficult and the people doing it are thoughtful, but a spec is written by whoever shows up, and that group skews heavily toward implementers.

Designers are almost never in the room, so who does this leave out? often arrives after the mortar has set.

The W3C's Accessible Platform Architectures (opens in a new tab) group exists for this. It reads emerging specifications for their effect on disabled people, while those specifications can still change.

I sit on it as an Invited Expert, and what strikes me about the work is how early it is.

We read about a feature that doesn't exist yet, in a document with no users, and try to see the failure before anyone can hit it.

It's less dramatic than it sounds. Mostly we read carefully and ask small questions. What does this expose to assistive technology?

What happens when someone navigates it with a keyboard, or magnifies it four hundred percent, or has animation turned off at the system level?

And then the one I'd hand to any designer reading this. Does the new feature give authors a faster route to an inaccessible result than to an accessible one?

If it does, most authors will take that route, and I'd call that a fault in the spec and not a failure of the authors.

A specification that makes the accessible path harder has decided something about the web.

Most designers will never review a W3C draft, and I'm not suggesting everyone should. But the cost of catching exclusion rises steeply with time, and most of our practice is organized around catching it late.

An audit is the most expensive moment. A ticket is cheaper, a design review is cheaper still, and a conversation before the component is designed is nearly free.

A comment on a draft, before anyone has built on it, is the cheapest thing our field can do, and almost nobody does it.

All of that has a version inside your own organization. Your design system has drafts, your platform team has RFCs, and your component library has a proposal process three people read. Those are your specifications.

Get on the list for whatever your team calls its pre-decision document, and read it before the release, because the comment period is the whole opportunity.

Then bring a failure mode with you. "This excludes screen reader users" gets nodded at. "A screen reader will announce this as 'button' with no name, because the label lives in a tooltip" gets fixed.

Cite the number too, since 4.1.2 is a shared reference and "it's not accessible" is an opinion someone must take on trust. And stay, because this work is won by the people still in the thread in week six.

Everything after the window is repair, which is always worth doing but never as good as the thing that was right when it was cheap.

The conventions being set right now, in tooling barely eighteen months old, are the specifications our successors will inherit. They cover keyboard behavior, focus, contrast and how a long-running job announces it has finished.

Almost none of it is decided, and the projects would take a patch from someone who turned up with one.

So find the draft nearest to you (a spec, an RFC, a proposal nobody has commented on) and ask the one question. Somewhere near you the mortar is still wet this week.