PDF remediation software can tag a document and flag missing alt text in seconds. It cannot tell you whether that alt text still makes sense once the document has been translated into four languages, or whether a reading order built for English still holds once German runs 25 percent longer.
Foliage Solutions runs remediation as a managed service specifically because the multilingual layer is where automated tools consistently fall short, catching structural problems while missing the semantic and cross-language issues that actually determine whether a document works.
This matters most for LSPs deciding how to handle remediation for multilingual projects: build the capability in-house with software, or bring in a specialist who handles the full workflow.
What PDF remediation software actually does
Remediation software falls into a few categories. Validation tools like PAC and veraPDF check a PDF against PDF/UA and WCAG requirements and report what passes or fails. Editor-based tools, Adobe Acrobat Pro DC being the most common, let someone manually tag structure, define reading order, and add alt text inside the document itself. Newer AI-assisted tools attempt to automate structural fixes directly, with mixed results depending on document complexity.
All of these tools do real, useful work. None of them were built with a second language layered on top of the original document in mind.
What automated tools reliably catch, and what they miss
Independent accessibility research is consistent on this point: automated checkers catch roughly one quarter to one third of accessibility issues on their own, before any manual review. They are genuinely good at structural checks: missing tags, empty links, unlabeled form fields, insufficient color contrast. What they consistently miss is semantic correctness: whether alt text actually describes what a reader needs to understand, whether a reading order makes sense to a person rather than just technically existing, whether a tag used as a heading is actually functioning as one.
A tool can confirm a language tag is present. It cannot confirm the tag matches the language actually sitting in that block of text. A tool can confirm alt text exists. It cannot confirm that alt text is accurate, or that it was ever translated at all rather than left in the source language after the visible text around it changed.
That gap between technically compliant and actually usable is exactly where multilingual documents fail audits that a single-language document would have passed.
Peer-reviewed benchmarking research comparing automated PDF accessibility tools against manual screen-reader testing found the same pattern repeatedly: tools can confirm a tag exists without assessing whether it is the correct tag for what it is describing. A heading tag applied to text that is not functioning as a heading passes the automated check and fails the person actually using a screen reader to navigate the document.
Why this gets harder specifically in a multilingual context
Run a remediation checker on a source-language PDF, and it evaluates what is actually there. Run the same checker on a translated version where the accessibility layer was never rebuilt to match, and the tool has no way to know that. It checks for the presence of structure, not whether that structure still corresponds to the correct language, the correct reading order for the new text length, or images whose alt text was ever updated.
This is not a flaw in the software. Remediation tools were built to evaluate a single document against a single-language standard. They have no concept of what changed between a source file and its translated counterpart, because that comparison sits entirely outside what the tool was designed to check.
A team running only automated checks on a translated PDF can get a passing report on a document that a screen reader user in the target language cannot actually navigate correctly. The report says compliant. The document is not.
Consider an LSP handling a healthcare provider’s patient information booklet, translated from English into Spanish and Vietnamese. Run each translated version through a standard checker, and all three might pass: tags present, alt text present, reading order technically defined. What the checker cannot catch is that the Vietnamese alt text still describes the image in English, carried over from the source file and never flagged because the tag itself is technically valid. A Vietnamese-speaking screen reader user gets an English description they cannot use. The compliance report says pass. The patient cannot actually access the information.
When software alone is the right call
Software-only remediation makes sense in specific situations. Single-language documents with straightforward layouts, low volume with no ongoing need to scale the process, and an in-house team that already has accessibility expertise to interpret what the automated checks actually mean, not just run them.
If your team has someone who understands PDF/UA and WCAG deeply enough to catch what the checker misses, software plus that expertise can work well for source-language documents. The gap opens specifically once translation enters the picture, or once volume makes manual review by an in-house generalist impractical.
Building that in-house expertise is a real option, not a lesser one. It just has a cost most teams underestimate: the person doing manual review needs to genuinely understand both the accessibility standard and what changes structurally when a document is translated, not just how to operate the checking software.
When a managed service is the right call
A managed service earns its cost in exactly the situations where automated tools are weakest: multilingual documents, especially anything with more than two target languages; regulated or client-facing deliverables where a failed audit has real consequences; complex layouts with tables, forms, or mixed content that automated tools handle inconsistently; and any team without dedicated in-house accessibility expertise to catch what a checker’s report does not surface.
The service is not replacing the software. It is adding what the software cannot do on its own: human review of semantic correctness, specifically tuned to what changes when a document moves from one language to several.
The cost comparison is not as simple as software subscription versus per-project fee. Factor in the hours an in-house team spends manually reviewing what automated tools miss, the cost of a failed audit discovered after delivery, and the risk of a compliance issue surfacing with an end client who has their own legal exposure. Software alone is cheaper per document until the gap it leaves open turns into rework, a missed deadline, or a client’s own compliance failure that traces back to your delivery
What Foliage adds beyond running the same checkers
We use the same category of validation tools as everyone else. The difference is what happens around them. Every remediated file gets a manual review of reading order and alt text accuracy, per language, not just a pass on an automated report. Language tags are checked against the actual text in each block, not assumed correct because a tag exists. And every delivery includes a remediation report documenting what was tested and how, the same structure covered in our broader work on multilingual PDF remediation.
That combination, automated tools plus targeted manual review built specifically for the multilingual gap, is what closes the space between technically compliant and actually usable.
How to test whether a service is worth the cost over software alone
Do not take a vendor’s word for what a managed service adds. Test it the same way you would test any DTP vendor claim: with a real file.
Take a document you have already run through automated remediation software, ideally one already translated into at least two languages. Send it to a prospective remediation service and ask them to review it, without telling them it already passed an automated check. If they come back with nothing beyond what the software already flagged, the service is not adding real value. If they catch language-tag mismatches, alt text still sitting in the wrong language, or reading order that breaks once expansion is accounted for, that is the gap a managed service exists to close.
A vendor who cannot find anything beyond an automated report is running the same checks you could run yourself for the cost of a software license, and that is worth knowing before you commit a full project to them, not after.
A practical way to decide
Ask two questions. How many languages does this document need to exist in, and does anyone on your team have the accessibility expertise to manually verify what an automated checker’s report does not cover. If the answer to the first is more than one and the answer to the second is no, software alone is very unlikely to catch the gap that matters most.
For a single-language, low-volume, internally reviewed document, software plus in-house expertise is often enough. For anything multilingual, client-facing, or regulated, the roughly 25 to 30 percent catch rate of automated tools alone is not a number most teams would accept if they saw it written on the compliance report itself.
Talk to Foliage Solutions about whether your next multilingual PDF project needs a managed remediation service or just a second look.
Leave a Reply