Marcelo Paiva
Theme

Where it stands

Two years on. The navigation crosses from the prototype into the product, our accessibility standard is answerable without me in the room, and I know exactly what I am building next.

Two years this month since that first week, when I could not open the product on my own laptop.

The navigation rail and information architecture have crossed from the boilerplate into the actual application. That is the sentence I most wanted to be able to write in September 2024, and it happened as a pull request rather than as a programme.

What is true now that was not then.

Our accessibility standard is a markdown file in the repository. When someone asked last month what conformance level the new platform targets, the answer came out of that file rather than out of me. That is the milestone I am proudest of, and it is a strange one to be proud of: the work is now answerable without me in the room. Any practice that depends on one person's availability is not a practice, it is a bottleneck with good intentions.

Agents read that file before they generate. The writing rules sit beside it, because words people cannot understand are an accessibility failure even when every automated check passes.

Mobile stopped being a second drawing made after the desktop one. It is the same code at a smaller width, so anyone can open it on a real phone the same day. When we chose navigation for the new platform we decided phone behaviour in the same session as desktop, including what the phone would deliberately skip at first release.

The test data ships with invented companies that look like our customers — logistics, nursing, food service, a university. Frontline and deskless work is the default case everyone starts from rather than the one you remember to check.

I am careful about what I claim. I am not saying our platform is fully accessible. We have older software and known gaps, and we publish conformance reports rather than adjectives. What changed is where the work happens: it used to be a check at the end, which is what produces eight presses of the Tab key, and it is now a property of the material everyone starts from.

Why this category of software, specifically. What we build decides who gets hired, onboarded and promoted. For many people it is the thing standing between them and a job. A hiring form that fails on a phone shuts out people without a laptop. An onboarding form that fails with a screen reader shuts people with disabilities out of work itself. The old process put both of those in the one place where they reliably lose — at the end, competing with the roadmap.

We stopped passing around pictures of our software. We started passing around the software.

What comes next, and I am clear about it. The design system becomes a product with its own users, versioned and released like one. The components go where outside experts can break them for us on real assistive technology. Discovery, requirements and prototypes stop living in three different places and start living next to the code they describe. And the loop keeps tightening until the distance between someone having an idea and someone else using it is measured in hours.

I have spent twenty years arguing that inclusive design is a property of how a team works rather than a stage in its process. This is the first time I have been able to build the machinery that makes it true, and it turns out to be less about conviction than about shortening the distance between a decision and the evidence that it was wrong.

That machinery is portable. I intend to build it again.