Putting our components in front of screen readers

You cannot properly test a component library with assistive technology when it sits behind a corporate VPN.

Screen readers are real software with real quirks. The people best placed to tell us whether our components work are not all on our payroll or our network: accessibility consultants, contractors, people in the community who will look at a thing and tell you the truth for free. None of them can reach us. That is not a minor inconvenience. It means the single most valuable source of feedback available to this team is switched off by default.

So I pushed to get our component documentation onto the open web.

It went up, and attached to it was internal engineering documentation that was never meant to leave the building. Colleagues spotted it immediately, said so, and we pulled public access inside a day.

My error was specific and I would rather name it than generalise it. I asked to make our documentation public. Our documentation contained material that could not be public. Both facts were available to me beforehand. I was thinking about the goal and not about the object I was proposing to move.

But the thing I want on the record is the cost. That whole episode took a day, because we had put something real out and let people look at it. I have sat in the alternative — six months of review meetings deciding whether publishing is acceptable in principle, with nobody ever looking at an actual artifact — and it costs fifty times as much and teaches you nothing.

I will take a corrected mistake over an uncorrected opinion every time, and I will keep building teams that work that way.

What I am now going to build toward: a components site that exists to be broken by people who do not work here. Outside experts, on real assistive technology, finding things we will never find ourselves. That is the fastest feedback loop available to an accessibility practice and almost nobody in enterprise software has it. We will.