Your vendor's accessibility is your accessibility

Signing is the last step of onboarding and the one with the least give in it. A new hire cannot start until the paperwork is signed, and for frontline staff that signature usually happens on a phone, standing up, somewhere between shifts.

The interface where it happens is almost never yours. It is a signing product you integrated, and it arrives with whatever accessibility it happens to have.

There are four normal responses to that. Wrap it and hope. File a request with the vendor and wait a quarter. Accept it and note the risk. Or replace it, which is months of work for a component that is not your product.

All four leave the same person stuck at the same screen.

The fifth option

DocuSeal is an open-source alternative to DocuSign — Ruby on Rails with Vue components. Open source means the fifth option is available: fix it, in the open, for everyone using it.

So I did, over a phased remediation:

• Semantic landmarks and the infrastructure to test against, first, because everything after is easier once a page has a real structure to hang from.
• Alt text across both halves of the stack — the Rails ERB views and the Vue submission form components. A split stack is where this work usually goes half-done: somebody fixes the framework they know and leaves the other half.
• Accessible names on icon-only buttons throughout. An unlabelled icon button is the single most common way a form becomes unusable with a screen reader, and a signing flow is almost entirely icon buttons.
• Keyboard support for the custom web components, which is where a signing product actually lives — the parts that place a signature, step through fields and submit are custom elements, and custom elements get keyboard behaviour only if somebody writes it.

Phase 1 reached 86%, tracked in the repository rather than in my head, so the remaining 14% is a list someone else could pick up.

The part I would do again

My first commit was not accessibility work at all. It was a CLAUDE.md documenting the codebase.

I do not write Ruby daily. Rather than spend two days building enough context to be useful, I spent the first hour making the codebase legible — to me, and to the agent I was working with. Everything after went faster, and the document is still there for the next person.

That is the same move I make at work, where the design rules and accessibility standard live as markdown in the repository so that both people and agents read them before generating anything. It turns out to work just as well in reverse: when you are the newcomer to an unfamiliar codebase, the first useful thing you can produce is a description of it.

It also settles a question I get asked often — whether AI assistance makes someone a tourist in a language they do not know. It does, on its own. Paired with actually knowing what accessible markup has to do, it makes you a useful tourist, in a codebase you would otherwise not have opened.

Why this one matters more than it looks

Our category of software decides who gets hired and onboarded. An onboarding form that fails with a screen reader does not inconvenience someone — it stands between them and the job they have already been offered.

The accessibility of the components you integrate is not the vendor's problem in any way your users experience. It is yours. They do not know where your product ends.

Where this goes

I would like the default reaction to an inaccessible dependency to be a pull request rather than a ticket.

Most teams never consider it, because the dependency feels like weather. But a great deal of the infrastructure underneath enterprise software is open source, staffed thinly, and would accept a well-made patch from someone who understood the problem. The people best placed to write those patches are the ones already losing arguments about accessibility internally — and a merged fix upstream is a much stronger argument than another slide.