The phrase turns up in scopes of work more often every year, and it is rarely defined in them. This page sets out what document compliance actually covers, what belongs in a scope of work, and what to require of a vendor — in language you are welcome to lift.
Document compliance is the set of duties that attach to a document the moment an agency publishes or retains it. They are usually owned by four different people, which is exactly why they are handled unevenly.
The document can be read by someone using a screen reader or keyboard alone. In practice this means a real text layer, a structure tree, reading order, alternative text and language — measured against WCAG 2.1 AA and PDF/UA-1 rather than asserted.
The document does not expose personal information it was never meant to publish — Social Security numbers, dates of birth, medical detail, signatures. Decades of scanned records are the usual source, and a black rectangle drawn over text is not redaction.
The document is kept for as long as its retention schedule requires and disposed of when that period ends, with the disposal documented. Publishing a record does not remove it from the schedule, and an archive nobody has inventoried cannot be scheduled at all.
The public can locate the document and staff can search it. This is the obligation most often left out of a specification, and it is the one that decides whether a records request takes ten minutes or three days.
Most document compliance scopes fail in the same place: they describe the outcome and not the evidence. Five things worth naming explicitly.
State how many documents and pages are in scope and how that number was arrived at. A count derived from a website crawl, a file share and a records system will differ, and a vendor bidding against an unstated number is bidding against a guess. Say what happens if the real figure is materially different.
“ADA compliant” is not a testable requirement. WCAG 2.1 Level AA and PDF/UA-1 (ISO 14289-1) are. Name the standard, name the version, and name the tool that will decide whether it has been met.
Require conformance evidence for each delivered document, not a percentage across the batch. When a complaint arrives it names one document, and a corpus-level score says nothing about that one.
Some documents cannot be remediated — image-only scans with no recoverable text, files whose source is lost, material covered by an archive exception. Require that these be identified and reported with a reason rather than quietly counted as done.
Define a sampling protocol you will run on delivery and the threshold at which a batch goes back. Without a rejection right the quality requirements are aspirational.
These are worth asking because the answers differ sharply between suppliers, and because each one has a wrong answer you can recognise without being a specialist.
A vendor grading its own output can define passing however it likes. An independent validator such as veraPDF produces a verdict the vendor does not control. Ask which one stands behind the delivered file.
Some tools leave the PDF untouched and present an accessible view through a viewer or overlay. That can be a reasonable choice, but the file you publish, email and archive is unchanged — and it is the file a complaint is about.
The honest answer is a list with reasons. Be wary of a process in which nothing ever fails, because in a real corpus a proportion always does.
Ask for the sub-processor list and a data processing agreement before award rather than after. If personal information is in scope — and in a records corpus it is — this belongs in the evaluation, not the onboarding.
A supplier of accessibility services that cannot document the accessibility of its own software is worth a second look. Section 508 procurement generally expects an Accessibility Conformance Report regardless.
A one-off remediation of a backlog leaves you non-compliant again within a year unless new documents are handled at the point of publication. Ask what the steady state looks like, not just the cleanup.
We wrote the requirements above the way we did because they are the ones we built the product to satisfy — accessibility, privacy and findability across a corpus, with per-document evidence from a validator we do not control.
Documents are repaired to WCAG 2.1 AA and PDF/UA-1 and then validated by veraPDF. A document that does not pass is returned with the reason named. Bulk remediation →
Personal information is detected across the corpus and removed rather than covered. PII detection →
VPAT on file, POs accepted, NET 30, and a sole-source justification if you need one. Procurement → · VPAT → · Sole source →
Send us the corpus you are writing the specification against. We will scan every page for accessibility and PII findings and return the counts, so the numbers in your scope of work are measured rather than estimated. POs accepted, NET 30, sole-source justification on file.