Guide
Merged PDFs and accessibility, which most of them fail
Updated
This is the part of the question nobody searches for and the part most likely to become somebody else's problem, particularly where the merged documents are published rather than posted.
What Section 508 guidance says
Section508.gov is direct about the format: PDFs "are still used across government, but they are often not the most accessible or mobile-friendly option".
And it states the resulting policy position plainly: "Federal policy requires agencies to prioritize HTML and use PDFs only when necessary." That is a hierarchy rather than a ban, and the word necessary is doing the work in it.
Why merged PDFs are worse than most
A merged document inherits its structure from the template, so a template with no heading styles, no tagged tables and no document language produces several thousand untagged files rather than one.
The volume is the problem. Fixing one PDF by hand is a task; fixing a pipeline's output afterwards is not possible, which is why the decision belongs before the pipeline is built rather than after it is running.
Scanned templates
A merge that starts from a scanned template inherits an image rather than text, and no amount of downstream care recovers it: there are no characters in the file for assistive technology or for any other reader to find.
This is more common than it should be, usually where a branded letterhead was scanned once and reused for years. Rebuilding the template as a real document is a one-off job that fixes every output after it.
The practical question to ask first
Does this need to be a PDF at all? A personalized statement that will be read on screen and never printed is a page, and generating a page is easier than generating a document.
Where a PDF genuinely is required, the work is in the template: heading styles, real tables, alternative text, a document title and a language setting, applied once and inherited by every output. That is cheap before the run and impossible after it.