Taggart

Bulk PDF remediation: triage before you automate

Thousands of documents and a deadline. How to find out what you actually have, what genuinely automates, and what does not.

Measure first

The most expensive mistake in a large remediation programme is committing to a schedule before knowing the distribution of work.

“Forty thousand documents” is not a plan. “Eleven thousand need work, of which two thousand need a person, and they are almost all from three templates” is a plan — and it usually takes a day to produce.

The census costs nothing. Taggart’s validator is free and unlimited precisely so this step is not a budget line.

The four buckets

Already usable. Tagged, sensible reading order, language set, alt text present. Usually anything exported properly from Word or InDesign. Leave them.

Mechanical only. Missing title, missing language, no DisplayDocTitle, headers not artifacted, TH cells without /Scope, tab order unset. No judgement calls anywhere. This is the bucket automation genuinely clears.

Needs a person. Broken reading order, untagged content, missing alt text, layout tables tagged as data. This bucket sets your schedule.

Not a PDF problem. Image-only scans with no text layer. These need OCR before anything else is possible — a different tool and a different budget line. Taggart detects them and points at ocrmypdf rather than building a worse OCR engine.

Running the census

Gather the files. Usually the slow part: they are in a CMS, a shared drive, and somebody’s laptop.
Validate everything, exporting JSON per file.
Bucket by finding id. A document whose only findings are 06-003, 07-001 and 11-001 is mechanical. One with 09-001 or 01-005 needs a person. One with no text at all needs OCR.
Cross-reference against usage. Your analytics know which documents are actually opened. A 2015 committee minute nobody has downloaded in three years is not the same priority as this year’s application form.
Now write the plan.

for f in corpus/*.pdf; do
  taggart check "$f" --json > "reports/$(basename "$f" .pdf).json"
done
jq -s '[.[] | {file: .source.path, blockers: .counts.blocker,
        rules: [.findings[].ruleId] | unique}]' reports/*.json

What the numbers usually show

Two things surprise people, and both are good news.

More documents are fine than expected. Anything from a well-built template usually passes. If your organisation standardised its templates at some point, everything after that date may already be in reasonable shape.

The failures cluster. They are rarely spread evenly — they come from one template, one author, or one year. Finding the cluster is worth more than fixing any individual document, because fixing the template fixes everything you publish from now on.

That second point is the whole argument for doing the census before the remediation. A programme that starts with the oldest document and works forward will fix ten thousand files and still be producing broken ones on the day it finishes.

Where automation genuinely helps

The mechanical bucket, applied in one pass per document, with a diff and an undo — and with the appearance gate on every output so nothing silently reflows across ten thousand files.

Everything else is a person with a good editor. The purpose of the tool is to make that person faster, not to replace them: the DOJ’s stated reason for extending the ADA Title II deadlines was that it had overestimated what staffing and technology could do here, and building a plan on the opposite assumption is how programmes miss deadlines.

Check a PDF free → · How to triage a backlog → · Pricing →

Frequently asked questions

Can a whole backlog be remediated automatically?

The mechanical layer can — language, titles, tab order, header scope, artifacting, role maps. Reading order and judgement calls cannot, and those are usually the ones that decide whether a document is usable. Any vendor claiming full automation is claiming the part the US Department of Justice specifically cited when it extended the ADA Title II deadlines.

What proportion of a typical backlog needs a person?

In our experience roughly a third are already usable, a third need only mechanical fixes, and a third need real work. Your distribution will differ — which is exactly why the census comes first.

Is batch processing available?

No. Taggart handles one document at a time, and there is no tier that changes that — no folder processing, no command line, nothing to buy that unlocks it. What it does do is the census: the free validator is unlimited and its JSON output makes bucketing several thousand documents a script you can write this afternoon. The remediation is then one file at a time, by a person, which is the part that was never going to automate anyway.

Should we outsource instead?

For a fixed historical archive, often yes — a service is a capital cost rather than a standing one. What outsourcing does not do is fix the templates that keep producing new documents, and that is where the recurring cost actually is.

Run your own file through it. The validator is free and unlimited — no page cap, no watermark, and no account at all up to 60 pages — so you can see exactly what you are dealing with before deciding anything.

Check a PDF free

Last updated 2026-09-10 . Competitor prices are as published by each vendor.