Guide

Rechecking PDF accessibility after a revision

A client sends version two of a PDF you already made accessible. Most of the document looks the same. This page covers why the earlier work may not have survived, which fix to try first, and how to recheck the new version without starting from nothing.

PDFCarry, 30 September 2026About 6 minutes

Why a revision undoes PDF-side work

When the fixes were made in the PDF itself, they belong to that file. A revised document is usually a fresh export from Word, InDesign or another authoring tool, and the export writes a new tag tree from the source. Headings you promoted, alternative text you wrote, reading order you corrected, table headers you marked and page furniture you set as artifacts are not in the source, so they are not in the new file.

Even when the tags do come through, you cannot tell from the page alone. Two versions can look identical while one has headings tagged as paragraphs. The reverse is also true: a single changed figure or moved paragraph can make an earlier reading-order check wrong while the rest of the page is untouched. Matching visible text is not evidence that structure, descriptions or relationships still hold.

First, fix the source if you can

If you or your client control the source document, fixing it there is the better answer. A Word file built with real heading styles, alternative text on its images and a marked header row on its tables, exported with tagging turned on, carries that structure into every future version. The same applies to an InDesign file with paragraph styles mapped to tags and objects given descriptions. The problem is removed at its origin, not managed after it.

That route is not always open. The source may belong to a designer you never deal with, arrive late with no time to change templates, or produce tags that still need hand correction on every export. In those cases the accessibility work happens on the PDF, and each revision puts some of it at risk.

The usual ways to handle version two

• Remediate the whole file again. Thorough and simple to reason about, and it repeats every check whether or not anything it depends on changed.
• Compare the versions and recheck what changed. Faster, but visual comparison misses tag changes, and deciding which earlier checks still apply is a judgement you then have to record somewhere.
• Reuse work with your existing tool. Equidox offers Zone Transfer and Page Match for revised or similar files. If you already use a reuse feature, assess it before adding another application. The comparison explains the overlap with PDFCarry.
• Run a checker and fix what it reports. Useful on every version. A machine checker covers the rules a machine can test; whether reading order makes sense, whether a description is accurate and whether headings reflect the document's logic still need a person.

A recheck list for the new version

Whichever route you take, these are the checks most often invalidated by a revision. Each starts unreviewed until you have looked at it on this version.

• –Is it the file you think it is? Record the file name, page count and a hash, so any later evidence can be tied to this exact version.
• –Does it still have tags? An untagged or partly tagged export changes the whole job.
• –Title and language. The document title and the default language are easy to lose in a re-export.
• –Headings. Check that headings are tagged as headings, at the right levels, and not flattened to paragraphs.
• –Reading order on changed pages. Added, removed or moved content can change the order around it.
• –Images and graphics. New or replaced images need descriptions; changed charts need their descriptions checked against the new data. Decorative graphics should still be artifacts.
• –Tables. Header cells and their scope, and whether a changed table still has the same structure.
• –Links. Link text and targets, especially where addresses changed.
• –Machine validation. Run a PDF/UA checker on the new file. A pass is necessary, not sufficient.
• –Record what you checked, on which version. A note of each check, who made it and when, stops the next revision starting from nothing.

Where PDFCarry fits

PDFCarry is built around that last item: it keeps the record and uses it when the next revision arrives. It is a Windows application that sits beside the editor you already use. The workflow is a sequence:

1. Import the reviewed, tagged baseline and record the checks you actually completed, per item, under your own name.
2. Import the client's revision. Checks whose content and context are unchanged keep their evidence. Changed or uncertain checks reopen, with the reason shown.
3. Correct titles, language, descriptions and text roles in the app, or edit the file in your usual tool and reimport it. A correction never counts as a review.
4. Export the PDF with a manifest of every check, who recorded it, when and on which version.

The first project costs real work: someone has to review the baseline and record what they checked before there is anything to carry. Any benefit starts with the second revision, and only when the revision stays inside what the engine can match. The worked example says the same and shows a full run on synthetic files, including a case where reuse is refused.

What PDFCarry does not do

• It is not a general PDF editor. Paragraph editing, re-tagging a whole document and repairing complex structure stay in your editor.
• It does not handle scanned documents, encrypted or signed files, interactive forms and XFA, or PDF 2.x.
• It refuses to carry complex or changed tables and content it cannot match with confidence; see the refused-table case. Tags are not preserved universally.
• A validator pass is not accessibility certification, and nothing is approved on your behalf.

The full envelope is on the front page under what it supports today.