Write a PDF remediation request around what the organization must receive and how it will evaluate the result. 'Make these PDFs accessible' leaves too many questions unanswered: which requirements apply, whether layout may change, who reviews content accuracy, and what happens when a delivered table is structurally valid but semantically wrong. Define those questions before comparing bids.
Describe the actual document population
Inventory file counts, approximate page counts, languages, source availability, scans, tables, forms, equations, signatures, and expected revisions. Identify the publication channels and reader tasks. A collection of simple letters differs materially from a smaller set of technical reports with complex diagrams. Give bidders enough authorized information to estimate the work without exposing confidential production files unnecessarily.
Create a representative evaluation set with synthetic or appropriately authorized materials. Include difficult patterns that occur in the real collection rather than only an easy brochure. State whether the supplier should repair source files, remediate existing PDFs, produce HTML, or deliver multiple formats. If exact visual layout is a constraint, say so and ask how the supplier will handle conflicts between appearance and usable structure.
State requirements and evidence separately
The U.S. government's guidance on accessible documents from business partners provides a public-sector example of setting expectations and ownership for delivered content. Its legal context should not be copied indiscriminately into every organization's contract. Have the responsible procurement and accessibility owners select the applicable standards, versions, and contractual language.
Specify the target PDF profile where relevant, the applicable accessibility criteria, and the review environments. Then define evidence: exact-file identifiers, validator names and versions, manual review records, known limitations, and a correction log. A requirement says what must be achieved; evidence explains why the reviewer believes a particular file achieves it.
Use observable acceptance tasks
| Area | Deliverable or task | Acceptance evidence |
|---|---|---|
| Content preservation | Retain approved wording, values, and meaningful visual information | Comparison with the approved source and owner review |
| Structure | Provide appropriate headings, lists, tables, figures, and order | Selected-profile validation plus documented manual inspection |
| Reader tasks | Find a section, interpret a complex table, follow a note, and complete a form where present | Recorded environments, expected behavior, findings, and retest |
| Version identity | Deliver the reviewed file and agreed editable sources | Manifest linking each artifact to its review record |
| Defect correction | Resolve agreed defects and explain any disputed finding | Issue log, corrected revision, and reviewer acceptance |
Avoid making a numerical checker score the sole acceptance condition. Some questions require content judgment, such as whether a figure description conveys the relevant result or whether a header identifies the intended cells. Make those responsibilities visible in the evaluation schedule so suppliers can price and plan the actual work.
Evaluate claims against the proposed work
Section508.gov's vendor information guidance explains requesting accessibility information during procurement. Ask how a supplier's evidence relates to the specific service and deliverables. A product-level conformance report does not by itself verify every PDF that a service later produces.
Request a sample result and its review record. Ask the supplier to explain an unresolved manual finding, a difficult table, and a case where source clarification was necessary. Evaluate the explanation and actual files using the agreed method. Do not equate a confident statement, a tool screenshot, or a generic certificate with demonstrated handling of the collection's difficult content.
Define defects, corrections, and release ownership
The accessibility acquisition playbook emphasizes evaluating conformance claims and incorporating testing into acquisition. For a remediation engagement, translate that principle into named reviewers, review windows, correction responsibilities, and a clear acceptance decision. These operational terms should be agreed through your procurement process, not assumed from a proposal's marketing language.
- Identify who can approve content changes and who can accept accessibility evidence.
- Define how defects are reported with file revision, location, expected behavior, and observed result.
- Agree how corrected files are retested and how related regressions are handled.
- Specify handling, access, retention, and return of source and output files through the organization's approved requirements.
- Make the publishing owner verify the accepted revision after upload to the final distribution channel.
Keep acceptance attached to the delivered version. If an organization edits or combines the file after acceptance, repeat the affected checks before publication. Use the complex table guide, screen-reader guide, and merge guide to define representative tasks. The sample schedule above is a drafting aid, not a guarantee that a particular contract satisfies legal or institutional requirements.
Frequently asked questions
Should a remediation RFP require a perfect checker score?
A checker score alone is an incomplete acceptance method. Specify the applicable requirements, automated validation, manual review tasks, exact-file evidence, and correction process so the evaluation addresses both structure and the intended meaning of the content.
Does a supplier's accessibility report cover every delivered PDF?
A report has a defined scope and version. Ask how it relates to the proposed service, then require evidence for the actual delivered files rather than assuming that a product-level statement verifies every output.
What makes a useful remediation evaluation sample?
Choose authorized or synthetic documents that represent the collection's difficult features, such as scans, complex tables, forms, equations, and multilingual content. Evaluate the result and review record against the same criteria intended for delivery acceptance.
Sources
The statements above rest on the primary sources below. Where a source is a law or standard, the version and date named in the text are the ones checked on the review date. This guide is general information, not legal advice.
- Section508.gov: Accessible documents from business partners . U.S. federal context; adapt requirements through the responsible procurement owners.
- Section508.gov: Request accessibility information
- Section508.gov: Accessibility acquisition playbook, Play 8
Keep reading
Section 508 document testing: the Baseline explained
The Section 508 ICT Testing Baseline for Electronic Documents (version 1.0, September 2024): its 24 tests, who wrote it, how it relates to the Revised 508 Standards and WCAG, and how to use it outside government.
Read the guide →Accessible PDF tables: complex headers
Work through multi-level headers, spanning cells, and tables across pages, then check whether a reader can identify each value's context.
Read the guide →How to test a PDF with a screen reader
A repeatable screen reader test for PDFs with NVDA, JAWS, or VoiceOver: which viewer to open the file in, the keystrokes to use, what to listen for, and independent data on which viewers expose tags.
Read the guide →