PDF Remediation Software, an In-House Team or a Provider? How to Choose for Documents in Several Languages
PDF remediation software can tag simple, consistent documents quickly, but on its own it rarely makes complex manuals, catalogues or forms compliant with PDF/UA and WCAG, because reading order, tables and alternative text need human judgement. DEMA Solutions helps companies decide which documents to fix at the source, which to automate and which to hand to specialists, in every language they publish.
Who this guide is for
This guide is for the people who decide how accessible PDFs will be produced: documentation managers with hundreds of manuals and data sheets, marketing managers with catalogues, compliance managers asked to prove that customer documents meet accessibility requirements, and procurement managers holding three proposals that look nothing alike.
If you need the basics first, our practical guide on how to make a PDF accessible explains tags, reading order, alternative text and the standards. This article starts one step later, with the questions that decide budget and risk. Can software do this for us? What skills would our own team need? When does a provider pay off? And what changes when every document exists in six or twelve languages?
What is PDF remediation, and why the "how" is a business decision
PDF remediation is the work of adding or correcting the hidden structure of an existing PDF so that assistive technology can read it: tags for headings, paragraphs, lists, tables and figures, a logical reading order, alternative text, artifacts, a declared language, a title and bookmarks. The target is usually PDF/UA (ISO 14289-1) for the file and WCAG 2.1 level AA for the content, which in Europe reaches documents through EN 301 549.
For one document, who does this hardly matters. For a company that publishes thousands of pages a year, it is a production decision. The same requirement can be met by your own staff, by software that automates part of the job, or by a specialist provider, and each has a different cost profile, a different failure mode and a different effect on the next update.
Underneath sits a timing question. Remediation in the strict sense repairs a finished PDF; the alternative is to build the structure into the source file so every export is already accessible. That choice often matters more than the choice between people and software.
Five questions that decide the answer
Before comparing options, describe your own document landscape honestly. Five factors decide most of the answer.
Volume and frequency. A backlog of two thousand archived reports that will never be edited is a different problem from forty manuals revised twice a year. Volume favours automation, frequent change favours fixing the source, and a one-off backlog favours outside capacity.
Languages. Every language version is a separate PDF that must be accessible in its own right, so the number of languages multiplies everything else in this list.
Complexity. Plain reports with a few headings are easy. Multi-column catalogues, spare parts lists with merged cells, technical drawings with callouts, warnings in boxes beside the step they qualify, and fillable forms are not. Complexity separates documents software handles well from documents that need people.
Evidence. A public buyer applying EN 301 549 in a tender, a customer in a sector covered by the European Accessibility Act requirements or an internal policy may each expect different proof, from an automated report to a full record of manual checks.
Source files. Without usable editable files, remediation has to happen in the PDF. With them, you have a cheaper and more durable option.
What PDF remediation software can do
Searches for the best PDF remediation tools return a long list of products, but they fall into a few categories that behave very differently, and the categories matter more than feature tables.
The first is the export and checking function built into authoring software: word processors, layout programs and structured authoring systems that produce a tagged PDF and run a basic check. For well-built documents it does most of the work before a PDF exists. The second is desktop PDF editing software with accessibility features, which lets a trained person edit the tag tree, reading order, artifacts and alternative text by hand; most professional remediation is done this way. The third is automated and AI-assisted remediation software, usually server or cloud based, which analyses the visual layout and generates tags, reading order, table structures and sometimes draft alternative text for many files at once. The fourth is validators, which test a file against the machine-checkable conditions of PDF/UA. The fifth sits upstream: document generation systems that produce tagged PDFs directly from templates or structured content, which is how high-volume statements and data-driven reports are best made accessible.
Automated PDF/UA remediation is genuinely useful for the right documents. It recognises paragraphs, infers heading levels from font size and weight, marks repeating headers, footers and page numbers as artifacts, builds simple tables with one header row, creates bookmarks, sets title and language metadata, and processes a batch in the time a person needs for one long manual. On simple, consistent layouts, the result may need only a review. Validators are fast and objective, catching untagged content, missing fonts and empty alternative text across thousands of files.
What automated remediation cannot do
The limits come from the same source as the strengths: software infers meaning from appearance. It sees that a line is large and bold, not that it is a warning title. Where the layout does not reveal the logic, it guesses, and in technical documents it guesses wrong often enough to matter.
Reading order is the clearest example. On a page with two columns, a sidebar, a safety box and a caption, there are several plausible orders and only one correct one, which depends on what the text means. A warning read after the step it qualifies is a safety problem, not a cosmetic flaw. Complex tables come second: spare parts lists and data sheets with merged cells, multi-level headers or page breaks need header relationships defined by someone who understands the data, or a screen reader user hears numbers without context.
Alternative text is the third. AI-assisted software can describe what an image looks like, but alternative text has to say what the image means at that point. “Exploded view of a pump” is a description; the useful alternative tells the reader which part the next step refers to, or that the figure repeats the text and can be marked as decorative. That needs product knowledge and the same approved terminology as the text. Software also struggles with language changes inside a document, forms with conditional logic, text embedded in images and colour-coded content.
Finally, passing a validator is not the same as being accessible. The Matterhorn Protocol, the PDF Association’s catalogue of PDF/UA failure conditions, separates failures software can detect from those that need human judgement, and a substantial part falls into the second group. A file can produce a clean automated report and still have a meaningless reading order, alternative text that says “image1” or headers attached to the wrong cells. An automated report alone checks whether the structure exists, not whether it works.
The skills an in-house team needs
Doing remediation in-house is realistic, but it is a specialist skill rather than an extension of office work.
The core skill is tagging: understanding the PDF tag set, repairing the tag tree, marking artifacts, defining table structures with header scope and fixing reading order in complex layouts. Next comes the judgement to write useful alternative text and decide which images are informative and which decorative. The third skill is testing: running validators, interpreting their reports and, above all, reviewing documents with a screen reader and the keyboard. A team that has never listened to its own manuals through a screen reader usually underestimates how many problems remain.
Upstream skills matter at least as much. Authors who use real styles, build tables properly and add alternative text as they write remove most remediation work before it starts, and templates that map styles to tags make every future document cheaper. Often the most effective in-house investment is not a remediation specialist but author training and corrected templates.
The risks are capacity and continuity. Remediation competes with other deadlines, one trained person is a single point of failure, and skills fade when used a few times a year. In-house works best for a steady flow of simple documents produced by people who also control the source.
Fixing at the source versus remediating the PDF
The most expensive pattern in accessible publishing is remediating the same document again and again. A manual is exported, remediated as a PDF, then revised three months later; the new export has none of the corrections, and the work starts again, in every language.
The alternative is to fix accessibility at the source. Styles are mapped to tags, reading order is defined in the layout file, alternative text is stored with the images, the language is set in the template and decorative elements are marked once. Each export then needs checking and finishing, not rebuilding. Preparing source files this way is what DTP file preparation involves, and the same work makes translation and layout cheaper.
Remediating the PDF directly still has its place: static documents, archives that must stay online, third-party files and documents whose source is lost. A sensible strategy treats the two as complementary: living documents are fixed at the source, frozen documents are remediated once, and an inventory says which is which.
Multilingual document sets
Multilingual documents are where the choice of approach has the biggest effect, and where most comparisons of software and providers say nothing. Each language version is its own file with its own tag tree, language declaration, reading order and alternative text, and it must be accessible on its own terms.
Translation and layout break accessibility in predictable ways. The document language stays set to the source, so a screen reader reads German text with Italian pronunciation. Text expansion pushes content into new frames and changes the reading order. Alternative text, bookmarks, titles and form labels are hidden from translators unless the process extracts them, so they stay in the source language. Automated software sees none of this: it will happily tag a Polish manual that declares itself English.
There are two ways to deliver an accessible set in eight languages. One is to translate, lay out and export each language, then remediate eight PDFs separately, multiplying the cost by eight at every revision. The other is to build accessibility into the source template, translate the hidden texts with the visible ones, adapt the layout in the source files and check each final language PDF. The checks are repeated per language; the structural work is done once. That second route only works if translation, multilingual desktop publishing and accessibility are planned together, and if alternative text follows the same approved terminology as the manual, which is why consistent terminology across translators and suppliers matters here too.
What drives the cost of PDF remediation
There is no useful universal price per page, and a quote based only on page count should raise questions. Effort follows structure, not length, and the drivers are the same whichever route you choose.
Starting point. A clean tagged export from a well-built source may need only correction and checks; a scanned document needs text recognition and a rebuild; a flattened PDF may be cheaper to recreate than to repair.
Complexity. Columns, sidebars, complex tables, forms and the number of informative images decide most of the hours. A parts catalogue with hundreds of illustrations is a different project from a report with five charts.
Languages and revisions. Each language version needs its own finishing and checks. As an illustration, a catalogue in six languages updated twice a year produces twelve accessible PDFs a year, and whether those are twelve remediation projects or twelve rounds of checks depends on where accessibility lives.
Evidence and turnaround. A documented manual review costs more than an automated report, and tight deadlines on large backlogs need more people at once.
In-house, the hidden costs are training, licences, time taken from other work and testing that gets skipped under pressure. With software, they are set-up, manual correction after automated tagging and the human review still required. With a provider, the cost is in the quote, which is comparable like for like only if the brief is precise.
In-house, software or provider: matching the option to the documents
Most companies with a large document estate end up with a combination. The useful exercise is to match each type of document to the approach that suits it:
- In-house, at the source: simple reports, letters, internal policies and presentations created by trained authors in templates that already map styles to tags, with an automated check before publication.
- Automated software with human review: large volumes of simple, consistently laid-out documents such as statements, data sheets or archived reports, ideally generated as tagged PDFs from templates rather than remediated afterwards.
- A specialist provider: complex manuals, catalogues and forms, multilingual sets, backlogs with a deadline, and any document where you need a documented manual review as evidence.
- Recreate rather than remediate: documents that are badly built, scanned or likely to change soon, where rebuilding a clean source costs less over its lifetime than repeated repairs.
Start with an inventory: which documents are current, which fall under a legal or contractual requirement, which are most used and which can be withdrawn. Part of many PDF archives should simply no longer be published, and the documents that matter most are often the ones that change most, which points back to fixing the source.
How to brief a provider
A provider can only quote accurately if the brief removes ambiguity about what “accessible” means. State the target standard and level, for example PDF/UA-1 and WCAG 2.1 level AA, or the exact tender requirement. Send representative samples rather than page counts, say whether editable source files exist, and give the languages and update frequency. Say whether the work should end with remediated PDFs or with corrected source templates, who will write or approve alternative text for technical images, what evidence you expect with each delivery and the deadline. Much of this is the same discipline as any good request to a language supplier, and what to send a supplier with a request for quotation covers the general habits.
How to evaluate PDF accessibility companies
Proposals from PDF accessibility companies often look alike on paper, so test how the work is actually done. Ask how reading order and alternative text are checked manually, and by whom. Ask for a validation record from a real project, with the automated report and the manual checks. Ask how much of the work is automated and how that output is reviewed, how translated versions are handled, whether they work in your source files or only on PDFs, and what happens at the next revision.
A paid pilot is the most reliable test. Choose your most difficult representative document, not your simplest, and compare results with a screen reader as well as a validator. Be wary of promises of full compliance through automation alone, of per-page prices given without seeing the files, and of deliveries with no evidence. When remediation is one link in a chain with translation and layout, the questions for checking a supplier’s quality before you hire them apply too, and fewer handovers mean fewer places for accessibility to break.
How DEMA Solutions handles PDF remediation
Our PDF remediation and PDF/UA accessibility service starts by reviewing how a document was built and proposing whether remediation should happen in the PDF or upstream in the source files. We audit structure, reading order, contrast, tables, images, links, forms and metadata; correct the source or remediate the PDF tags; add the semantic information; verify reading order and usability with accessibility tools and a review of how content is exposed to assistive technology; and deliver the file with the agreed validation evidence.
The difference is the connection with translation and layout. Our in-house DTP team already works in the source files of manuals and catalogues, so accessibility becomes part of the output specification during multilingual desktop publishing rather than a separate project at the end, and the checks are repeated on the final file in every target language. Translations follow our ISO 17100 certified process, with a second qualified linguist revising every translation, and our broader accessibility and inclusive language services cover plain language and easy-to-read versions where documents also need to be easier to understand. Our teams work in Italy, Serbia and Spain.
Where TUBE fits
For manuals and catalogues republished in several languages with every revision, TUBE keeps the language of each edition under your control. Your glossary and translation memory control machine translation, every approved translation goes into a memory you own and can export, and leverage reporting shows how much of each update comes from text you have already approved.
Frequently asked questions
It is the process of adding or correcting the internal structure of a PDF so that assistive technology can read it: tags, reading order, alternative text, artifacts, table headers, document language, title and bookmarks. The usual targets are PDF/UA (ISO 14289-1) for the file and WCAG 2.1 level AA for the content.
For simple, consistently laid-out documents it can produce a good starting point, but not a verified result. Reading order, complex tables and meaningful alternative text need human judgement, and part of the PDF/UA conformance criteria cannot be checked by software at all, so a manual review is still required.
A validator tests a file against the conditions that can be checked automatically and reports failures. Remediation software changes the file by adding or correcting tags and structure. Neither replaces a human review of reading order, tables and alternative text.
Fix the source when the document will be revised or translated, so that every new export inherits the structure. Remediate the PDF when the document is static, comes from a third party or has no usable source.
Each language version must be accessible on its own, so each needs its own checks. If accessibility is built into the source template and the hidden texts are translated with the visible ones, the structural work is done once and only the checks are repeated per language.
Effort depends on the document's structure rather than its length: the quality of the starting file, layout complexity, tables, images, forms, the number of languages and the evidence required. A reliable quote is based on representative sample files rather than a page count.
Yes, for a steady flow of simple documents, provided the team is trained in tagging, reading order, table structure, alternative text and screen reader testing, and authors use accessible templates. Complex, multilingual or deadline-driven work usually needs additional specialist capacity.
Decide with your own documents
If you are weighing software, your own team or a provider for documents in several languages, send us two or three representative PDFs and tell us which languages you publish in. We will review how they were built and recommend where remediation should happen, in the PDF or in the source, for each type of document.
How can we help?
Tell us what you need and we’ll get back to you with the solutions.