Whose accessibility is it when you did not build it?

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

The signing interface is not ours. We bought it. It is embedded in our flow, wearing our logo, reached from our email, and if it does not work for this person, they do not experience that as a vendor problem. They experience it as this company does not work for me, on day one, before they have met anyone.

Where does our responsibility actually stop?

We tend to draw the line at the repository boundary. Our code, our problem; their code, their problem. It is a tidy line and it matches how budgets work.

The person on the other end draws no such line, and I think they are right. From where they stand it is one product. The seam we can see is invisible to them, and invisibility is rather the point of a good integration. We spent effort making it feel seamless, and we do not get to un-spend that effort when it becomes inconvenient.

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

That is uncomfortable, because it means owning something we cannot merge a fix into. It is still true, and I would rather our field said so plainly than kept a boundary that only protects us.

Who is actually excluded here?

Let me be specific about who, because "accessibility issue" is a phrase that lets everyone stay comfortable.

A signing flow that fails at 375 pixels excludes people who do not own a laptop. A flow that cannot be completed with a keyboard excludes people who do not use a mouse. Unlabeled form controls, a 4.1.2 failure, exclude anyone using a screen reader. A session that times out without warning excludes people who read slowly, people using switch access, and anyone interrupted by the job they were just hired to do.

Notice who that is together. Hourly workers. People completing this mid-shift on a personal phone. New hires, who have the least standing of anyone in the organization to complain, which makes them the group least likely to generate the ticket that would tell us it is broken.

The absence of complaints from that group is not evidence that it works. It is evidence that we have built a system where the cost of complaining exceeds the cost of struggling through.

Is the vendor the villain?

No, 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. This is the same unexamined-default problem we have inside our own organizations, one company removed.

What changes outcomes is not accusation. It is arriving with a specific, reproducible finding, at a moment when someone has a reason to act on it.

What can we do when we cannot merge a fix?

This is the part that felt hopeless to me until it did not.

• Test the vendor's flow as part of our flow. Not the accessibility report they supply, the actual screens, on an actual phone, with a keyboard and a screen reader. A conformance document is a claim; 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 answering "we are fully compliant" without a caveat has not tested, because nobody who has tested says that.
• Put findings where the commercial relationship lives. A bug report to support enters a queue. The same finding attached to a renewal conversation becomes a priority. That is not cynicism; it is how organizations allocate effort.
• Fork it if the license allows. Sometimes the fastest path is to fix it yourself, in a language you do not write daily, and offer the patch back. It is 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, a human. Not as "the accessible option", which is segregation with extra steps, but so a broken third party cannot become a broken hiring process.
• Write the requirement into the contract next time. The cheapest moment to fix vendor accessibility is before the signature, and it is the moment we consistently skip.

The pattern underneath

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

That is this blog's argument applied to a boundary I did not draw. The defaults of the software we buy are as unexamined as the defaults we write. We are still the people best placed to catch them, because we are the ones who put the thing in the path.

Open one integration you did not build this month. Try it on a phone. Try it with the keyboard only. Twenty minutes, and you will know something about your product that your vendor's documentation will not tell you.

Then tell them what you found. We cannot fix every seam, but let's stop pretending the seam is where our responsibility ends.