Whose accessibility is it when you did not build it?

The signing screen in our onboarding flow wasn't ours. We bought it.

Picture the first day anyway. Someone has been hired, and they're standing in a break room between shifts, signing onboarding documents on their phone.

The screen is embedded in our flow, it carries our logo and people reach it from our email. If it doesn't work for this person, they won't see a vendor problem.

They'll think this company does not work for me, on day one, before they have met anyone.

To the person signing, it is one product

We tend to draw the line at the repository boundary, so our code is our problem and their code is theirs. It's a tidy line and it matches how budgets work (which I suspect is most of its appeal).

The person on the other end draws no such line, and I think they're right. From where they stand it's one product.

They can't see the seam we can see, and that's what a good integration is supposed to do. We put effort into making it feel seamless, and we can't take that effort back when it becomes inconvenient.

So my position is that our obligations follow the experience and not the codebase. If we put it in the path, we own how it behaves in that path.

That's uncomfortable, because it means owning something we can't merge a fix into. I'd still rather our field said so plainly than kept a boundary that only protects us.

"Accessibility issue" is a phrase that lets everyone stay comfortable, so here is who I mean. A signing flow that fails at 375 pixels excludes people who don't own a laptop.

One that can't be completed with a keyboard excludes people who don't use a mouse. Unlabeled form controls, a 4.1.2 failure, exclude anyone using a screen reader.

And a session that times out without warning excludes people who read slowly and people using switch access. It also excludes anyone interrupted by the job they were just hired to do, which is a strange thing to have to write down.

Put those together and it's hourly workers, finishing this mid-shift on a personal phone. They're also new hires, who have the least standing of anyone in the organization to complain.

That makes them the group least likely to file the ticket that would tell us it's broken.

So I don't read the absence of complaints from that group as evidence that it works. I read it as a sign that we've built a system where complaining costs more than struggling through.

It would be easy to make the vendor the villain at this point. I wouldn't, and framing it that way reliably makes things worse.

Most vendors in this position are small teams who have never been asked the question. Their procurement conversations were about features and price. Their conformance document was written once, by someone under deadline, possibly without testing.

It's the same unexamined-default problem we have inside our own organizations, one company removed. The defaults of the software we buy are as unexamined as the defaults we write.

A specific finding does more than an accusation

This part felt hopeless to me at first, and it no longer does.

I'd skip the accusation and arrive with a specific, reproducible finding, at a moment when someone has a reason to act on it. That's what changes outcomes, and most of what follows is a way of doing it.

• Test the vendor's flow as part of our flow. Test the actual screens on an actual phone, with a keyboard and a screen reader. Their conformance document is a claim, and a recording of the failure is a fact.
• Ask in procurement, in writing, before signing. Which WCAG 2.2 criteria do you fail today, and what is the plan? Anyone who answers "we are fully compliant" without a caveat hasn't tested, because nobody who has tested says that.
• Put findings where the commercial relationship lives. A bug report to support enters a queue, but the same finding attached to a renewal conversation becomes a priority. I don't mean that cynically. It's how organizations decide where effort goes.
• Fork it if the license allows. Sometimes the fastest path is to fix it yourself, in a language you don't write daily, and offer the patch back. It's less heroic than it sounds and more effective than waiting.
• Keep a path that does not depend on them. A phone number, a paper form or a human. It isn't "the accessible option", which is segregation with extra steps. It keeps a broken third party from breaking hiring.

Next time, I'd also write the requirement into the contract. The cheapest moment to fix vendor accessibility is before the signature, and it's the moment we consistently skip.

Every one of those is the same move. We get the problem in front of someone early, while it's still cheap to change, and we make sure the person who can act on it can see it.

We're still the people best placed to catch these things, because we're the ones who put the thing in the path. We can't fix every seam, though.

So this month, open one integration you didn't build. Try it on a phone, then try it with the keyboard only. In twenty minutes you'll know something about your product that your vendor's documentation won't tell you.

Then tell them what you found.