When is a standard still cheap to change?
A bricklayer has about ninety minutes to move a brick, and I keep thinking our specifications work the same way.
A bricklayer can move a brick for about ninety minutes. After that the mortar has set, and moving it means breaking something.
Web platform features work the same way. There is a window (sometimes months, often longer) where a specification is a draft, its edges are soft, and a well-argued comment can change it. After it ships into browsers and into a million pages, the same change costs a decade and a migration guide.
Where do inaccessible defaults actually come from?
Rarely 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. In a specification, by people solving a different problem, with accessibility as one concern among many.
I do not 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 the set of people who show up skews heavily toward implementers. Designers are almost never in the room, which means the question 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 exactly this: reading emerging specifications for their effect on people with disabilities, while those specifications can still change. I sit on it as an Invited Expert, and the striking thing about the work is how early it is. You are reading about a feature that does not exist yet, in a document with no users, trying to see the failure mode before anyone has had a chance to hit it.
What does that work actually look like?
Less dramatic than it sounds, and more useful.
Most of it is reading carefully and asking small, concrete questions. What does this expose to assistive technology? What is the accessible name of this new thing? What happens when someone navigates it with a keyboard, or magnifies it four hundred percent, or has animation turned off at the system level? Does this new feature give authors a faster route to an inaccessible result than to an accessible one? If it does, most authors will take it. That is a fault in the spec, not a failure of the authors.
That last question is the one I would hand to any designer reading this. Defaults are not neutral. A specification that makes the accessible path harder has decided something about the web, and it decided it quietly, in a document.
What does this have to do with the rest of us?
Most designers will never review a W3C draft, and I am not suggesting everyone should.
But the pattern generalizes, and the pattern is the point: 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. A conversation before the component is designed is nearly free. A comment on a draft, before anyone has built on it, is the cheapest intervention available to our field, and it is the one almost nobody makes.
Every layer of that has a version inside your own organization. Your design system has drafts. Your platform team has RFCs. Your component library has a proposal process three people read. Those are your specifications, and their mortar is still wet.
How do you get into the window?
- Read the RFC, not the release. Whatever your team calls its pre-decision document, get on the list. The comment period is the whole opportunity.
- Ask one question, consistently. Who does this leave out? It works on a W3C draft, a component proposal, and a ticket. It is not an accusation, and it does not require being the expert in the room.
- Bring a failure mode, not a principle. "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. WCAG criteria have IDs for a reason. 4.1.2 is a shared reference; "it's not accessible" is an opinion someone must take on trust.
- Check which path is easier. If the accessible implementation takes more code than the inaccessible one, say so. That is a design flaw in the proposal, not a training problem for its users.
- Show up more than once. Standards work and design system work are both won by the people still in the thread in week six.
The part I keep returning to
Accessibility is applied early or it is not really applied at all. Everything after the window is repair, always worth doing, 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. Keyboard behavior, focus, contrast, 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.
Find the draft nearest to you (a spec, an RFC, a proposal nobody has commented on) and ask the one question. The mortar is wet somewhere near you this week.