Split it in two before you test anything. The signing interface belongs to your vendor, and you can ask them for evidence about it. The document travelling through that interface belongs to you, and no amount of vendor conformance makes an untagged contract readable. Teams that skip this split end up auditing one half twice and the other half never, usually the half they own.
The second thing to settle early is that signing a contract is a legal commitment, and that single fact pulls a specific rule into the middle of the review. It also means the whole route counts as one process rather than as a set of pages, so a barrier at the confirmation step is not a small finding at the end. It is a barrier in the middle of something somebody is legally committing to.
The Vendor Splits the Product Before You Do
Look at how the best-known platform publishes its own evidence and the shape of the problem appears immediately. Docusign's accessibility hub does not carry one report. It carries separate conformance reports for the signing experience and the sending experience, and then separate ones again for its contract lifecycle product, its web forms, its workspaces, its notary product, its workflow builder and its iOS app.
So "our e-signature platform is accessible" is not a sentence the vendor's own hub supports, and that is not a criticism of the vendor. It is what honest reporting looks like when the product is really a family of them. What it means for you is that the report you were handed covers one of those surfaces, and the first question in any review is which one. A sending report says nothing about what your customer meets.
The same hub also names recommended browser and screen reader combinations, which is another scoping fact rather than a limitation on anybody's rights. It tells you which environments the vendor's evidence is most likely to describe, and it tells you where a test of your own is most likely to disagree with the paperwork. Read a conformance report the way what a VPAT cannot tell you suggests, and treat the environment line as part of the finding rather than as boilerplate.
Signing Is a Legal Commitment, and a Rule Turns On That
3.3.4 Error Prevention (Legal, Financial, Data) applies at Level AA to pages that cause legal commitments or financial transactions, and a signature page is the clearest example there is. The rule is satisfied by any one of three things, which is the part that saves arguments. Submissions are reversible. The data is checked and the user can correct it. Or a mechanism exists for reviewing, confirming and correcting before the thing is final.
Any one. Not all three. A signing flow that lets somebody read the whole document, see every field they filled, and go back and change one before pressing the last button has met the criterion through the third route, and it does not also owe you a cancellation window. Knowing that stops a review turning into an argument about whether contracts should be undoable, which is a business question and not this one.
The rule underneath it is the process rule. When a page is one of a series presenting a process, every page in the series conforms at the level claimed or none of them does. A signing journey is a series by any reading, so the audit runs the route rather than sampling it. That is also why the confirmation screen is not an afterthought. It is inside the same conformance boundary as the signature itself.
The Six Surfaces, and Who Owns Each One
Run the matrix below on a test envelope rather than a live one, using an agreed sandbox and synthetic parties. Each row is a place the journey can stop, and the owner column is the one that decides where a finding goes.
| Surface | Who owns it | What the evidence has to show |
|---|---|---|
| The invitation | You, mostly | An email whose subject and body say what is being signed and by when. Link text that names the action rather than reading Review Document |
| Arrival and identity check | Shared | Whatever stands between the link and the document. An access code, a one-time passcode, a login. Test it with the keyboard and with a screen reader, and record what a failed attempt sounds like |
| The document view | You | The file you uploaded, tagged, in a sensible reading order, with real headings. A viewer cannot invent structure the file never had |
| Fields and errors | Shared | Every field reachable and named, with the platform's tooltip carrying the label. Required fields announced as required, and a validation failure that says which field and why |
| Signature capture | Vendor | A route to a signature that does not require drawing with a pointer. Typed and adopted signatures reached by keyboard, and the choice announced |
| Confirmation and the final file | Shared | A confirmation that reaches a screen reader, and a completed document that is still tagged after the platform has written the signature into it |
The last row is the one that surprises people. A platform flattens, stamps and reassembles the file on the way out, so the document you get back is not byte for byte the document you put in. Test the completed copy as its own artifact, because a tagged contract that comes back untagged is a finding nobody would have looked for.
The Document You Uploaded Is Still Your Document
This is the half that gets orphaned. Signing platforms overlay their own fields on top of your file, and the platform's tooltip on each field becomes what a screen reader announces. So a tagged contract with well-drawn fields reads properly, and an untagged one reads as a wall of unlabelled boxes on top of a document nobody can navigate. Neither outcome has anything to do with the vendor's conformance report.
Which means the preparation work is a document job, and it belongs with whoever produces the contract. Tag the source, set the language and the title, mark the tables properly, and give every field a tooltip that says what it is rather than repeating its position. All of that is in what makes a PDF readable and how to tag a PDF, and none of it can be done after the envelope has gone out.
Sessions Expire, and That Is a Rule Too
Signing sessions time out, which makes them a time limit set by the content, which puts them under 2.2.1 Timing Adjustable at Level A. Three routes satisfy it. Let the user turn the limit off before they meet it. Let them adjust it before they meet it, over a range at least ten times the default. Or warn them before it expires, give them at least 20 seconds to extend with a simple action, and let them do that at least ten times.
Test it by leaving the session open and going to make a coffee, which is the same thing your customer does when a contract asks them to read something long. What you want to know is whether a warning arrives, whether it reaches a screen reader, and whether anything they typed survives the timeout. And while you are in there, look at whether the flow asks for the same information twice, because 3.3.7 Redundant Entry landed at Level A in WCAG 2.2 and a signing flow that re-asks for an address is exactly what it is about.
What This Review Cannot Tell You
Say this part out loud at the start of the engagement rather than at the end. An accessibility review of a signing journey establishes whether disabled people can complete it. It establishes nothing about whether the resulting signature is legally binding, whether the identity check is strong enough for your regulator, or whether the platform's security holds up. Those are three separate specialisms and none of them is ours.
It also cannot be run on live contracts. Real envelopes go to real people and create real obligations, so the review needs an agreed sandbox, synthetic signers and test documents that nobody will mistake for the genuine article. That is a scoping question rather than a purchase, and it is why this work starts with a conversation.
One honest limit
There is no e-signature package on our price list, because a journey that crosses a vendor's product and your own document is scoped rather than counted. The closest matched doors are the forms and errors audit for the field-level half and the PDF accessibility audit for the document. For the whole route, tell us what the journey looks like through contact and we will tell you what can be tested and what cannot.