My recommendation: before quoting a PDF-remediation job, run one check first — does the file have an extractable text layer. Select a sentence with a cursor. If nothing selects, the document is at least partially rasterized, and everything else in the proposal has to follow from that answer, not from what the client hopes the answer is.
I learned this scoping two document-accessibility proposals under the Samarthyam brand, for two prospective clients. Neither converted into paid work. Both diagnoses were correct. That's the part worth writing down — an honest "no" from a client is sometimes the right outcome of a proposal, not a failure of the proposal.
What a PDF/UA assessment actually checks
Most people who've heard of an accessibility standard have heard of WCAG, built for web pages rendered in a browser. PDF has its own standard: PDF/UA-1, formally ISO 14289-1, published by ISO and maintained by the PDF Association. Where WCAG checks a page's DOM — headings, labels, focus order — PDF/UA checks a tag tree embedded inside the PDF file itself: a parallel structure that tells a screen reader what each element actually is (a heading, a figure, a table cell, a list item) and in what order to read it, independent of how the page looks visually. Two PDFs can look identical to a sighted reader and be opposite in what a screen reader announces, depending entirely on whether that tag tree exists and is correct.
A PDF/UA-1 assessment checks, roughly in this order:
- Whether the document has a genuine, extractable text layer at all — the precondition for everything below.
- Whether it's tagged, and whether the tags describe the real content structure rather than a generic default.
- Whether images carry alternative text.
- Whether the reading order encoded in the tag tree matches the visual reading order.
- Whether the document declares a language and carries a title.
That first check decides the shape of the whole engagement. Everything after it is detail.
Two documents, two different problems
The first, a comic-format PDF, was originally built in Canva. Independent testing put it at roughly 70% PDF/UA conformant — most of the tag structure was already present and largely correct, which is common for documents exported from a modern design tool. The gap was specific and bounded: 82 of 114 figures were missing alt text, the cover title was split awkwardly across two tag elements, and reading order needed a manual verification pass. Every one of those is an in-place fix — open the existing structure, add what's missing, correct the order. That's genuine remediation: repair the file that already exists.
The second, an accessibility toolkit PDF, looked, at a glance, like the same category of job. It wasn't. Independent testing found it fully rasterized across all 76 pages: no extractable text anywhere, no tags, no language attribute, no title. Functionally, every page was a picture of a page. The most likely cause was a print-to-PDF export from whatever tool the toolkit had originally been laid out in — a common production path, not a rare mistake, and one that flattens the finished page into a flat image while discarding the text and structure underneath it entirely. There was no tag tree to repair, because none had ever been embedded in the file. A screen reader pointed at that document finds nothing to read — not bad content, no content.
That's not a bigger version of the first problem. It's a different problem, with a different fix. The comic PDF needed a skilled hour inside its existing tags. The toolkit PDF needed to be rebuilt from its original source — Figma, InDesign, whatever it had actually been laid out in — and re-exported through a pipeline that preserves and tags structure on the way out. Remediation and re-authoring are different engagements: different skills, different timelines, and very different costs. Quoting one when a file needs the other is how an honest proposal turns into a project nobody can finish on the scope that was actually sold.
Why the honest scope was the harder sell
I scoped both proposals for what the files actually needed: bounded remediation for the first, a re-authoring engagement for the second. Neither converted, and I don't think that's a coincidence, and I don't think it means the diagnosis was wrong. A remediation quote reads as a fix. A re-authoring quote reads as starting over, even when starting over is the only path that produces a document that actually passes PDF/UA. The honest version of the second proposal was always going to be a harder conversation than the first, because it was correctly asking for more.
The alternative was available, and I didn't take it: scope the rasterized file as if a lighter remediation pass could get it most of the way there, deliver something that improves the surface without touching the underlying problem, and let the real gap surface later, on somebody else's audit. That proposal probably wins more often. It also sells a result the work behind it can't produce — and a rasterized PDF quoted as a remediation job is a promise the file itself makes impossible to keep.
The check I run first now
- Open the file and check for an extractable text layer before anything else. If nothing selects, treat the file as at least partially rasterized until proven otherwise.
- If it's tagged and mostly there, scope it as remediation: count what's actually missing — alt text, labels, reading-order fixes — and quote against that count.
- If it's rasterized, say so plainly in the proposal, and quote re-authoring from source. Not a discount version of remediation that structurally cannot deliver PDF/UA conformance on that file.
- Treat a lost proposal built on an honest scope differently from a lost proposal built on a wrong one. Only the second is a mistake worth changing anything about.
Related: on why a check is only as trustworthy as the question it actually asks, see A Check Is Only As Honest As Its Name — the same discipline applies to a PDF/UA assessment as to a CI gate: read the name as a claim, then confirm the check in front of you actually tests it.