Accessible PDFs: convert to HTML, or remediate in place?

There are two honest ways to make an inaccessible PDF usable by a screen reader. You can convert it to semantic HTML and publish that instead, or you can remediate the PDF in place — add the tag tree, fix reading order, associate table headers, write alt text — and keep shipping a PDF.

Both camps have real organizations, real standards, and real reasons behind them. The argument usually gets framed as a format war (“PDFs are dead” vs “PDF/UA exists for a reason”), but the format is the cheap part. The expensive, error-prone work sits upstream of both outputs, and it’s the same either way: recovering what the document actually means.

And the baseline is grim enough that doing nothing isn’t an option for anyone. A 2024 University of Washington analysis of ~20,000 scholarly PDFs found that fewer than 3.2% satisfy all six accessibility criteria tested, while 74.9% meet none of them (Kumar & Wang, “Uncovering the New Accessibility Crisis in Scholarly PDFs,” arXiv:2410.03022, ASSETS 2024). The format ships broken by default. The only question is what you do about it.

This post sources both sides, lays out the evidence, and ends with a framework you can apply per document instead of per ideology.

The case for HTML-first (“PDF as a last resort”)

The strongest version of this argument doesn’t come from a vendor. It comes from national government digital authorities and a vendor-neutral usability lab — people with no conversion tool to sell.

Who	Stated position	Source
UK Government Digital Service (GOV.UK)	“The default should be to create all content in HTML. If you can’t avoid publishing a PDF, ideally it should be in addition to an HTML version.”	Neil Williams, Why GOV.UK content should be published in HTML and not PDF (2018)
GOV.UK (official guidance)	“Creating a new document as PDF is a last resort and should be avoided unless there is a specific business need.” Publish in HTML “so that your documents use your users’ custom browser settings.”	Publishing accessible documents (updated Oct 2025)
UK Office for National Statistics	”We do not publish PDF-only or Word-only content on the ONS website… PDF files are less accessible than HTML pages, so should not be used without an HTML alternative.”	ONS Service Manual
US GSA / Section508.gov + OMB	”Federal policy requires agencies to prioritize HTML and use PDFs only when necessary” — implementing OMB’s binding government-wide mandate.	Section508.gov; OMB M-24-08
Nielsen Norman Group	”Do not use PDFs to present digital content that could and should otherwise be a web page.”	Nielsen & Kaley, PDF: Still Unfit for Human Consumption, 20 Years Later (2020)

The federal version of this is not a suggestion — it’s a binding government-wide mandate. From OMB Memorandum M-24-08:

Agencies should use HyperText Markup Language (HTML) as the default when creating and publishing content online in lieu of publishing content in other electronic document formats that are designed for printing or preserving and protecting the content and layout of the document (e.g., PDF and DOCX formats)… This practice makes web content easier to find, use, and maintain, and makes it work more reliably with assistive technology.

Their reasons, distilled:

• Accessible by default. Headings, lists, and tables in HTML carry semantics natively. A screen reader gets structure for free; in a PDF that structure has to be added back with tags.
• Reflow and mobile. HTML reflows to any screen. GOV.UK’s argument is blunt: PDFs “generally require a lot of zooming in and out, and scrolling both vertically and horizontally.” (Fair caveat: a well-tagged PDF can partially reflow in Acrobat’s Reflow view or Reader’s Liquid Mode — the reflow gap is real but narrowing, not absolute.)
• Custom browser settings. HTML respects a user’s chosen colors, fonts, and text size. A fixed-layout PDF overrides them.
• Maintenance. Fix a typo in HTML and the accessibility survives. Re-export a PDF and the tag tree is often gone — the remediation investment evaporates on the next edit.

One honest, contested point lives here. NN/g calls PDF “inherently inaccessible,” and GOV.UK states that “PDF and PDF/A cannot be made fully accessible to all users of assistive technology.” Present those as positions, not settled physics — the tagged-PDF camp disputes them (more below), and the dispute really turns on “compliance/conformance” (achievable in PDF) versus “fully accessible to every AT user” (which no format, HTML included, can guarantee).

A skeptic’s note on who’s talking. The cleanest HTML-first advocates above are vendor-neutral: governments have no commercial stake, and Nielsen Norman Group sells no conversion tooling. Be warier of the AI “PDF→HTML” converters and one-click “accessibility overlays” that wrap the same advice around a product — automated fixes have repeatedly failed to shield organizations from accessibility litigation (Overlay Fact Sheet, signed by hundreds of accessibility practitioners). “Just convert it automatically” is marketing, not a compliance guarantee.

The case for fixing the PDF in place

The counter-argument is grounded too: for a large class of documents, the PDF is the artifact of record, and converting it away is illegal, lossy, or operationally impossible.

Who	Stated position	Source
PDF Association	A properly tagged PDF conforms to a real accessibility standard — PDF/UA (ISO 14289). Authors the standard and the conformance test suite.	Busting the myth that PDF cannot be accessible; Matterhorn Protocol
Adobe	PDFs can and should be made accessible — Acrobat’s accessibility tools and the Auto-Tag API exist to tag PDFs toward PDF/UA and WCAG.	Adobe PDF Accessibility Auto-Tag API
Remediation practitioners (Deque, Allyant/CommonLook, AbleDocs)	Tagging is a defined, deliverable, validated process — tag structure, reading order, table headers, alt text, then validate.	Deque, 8-step PDF accessibility checklist

Their reasons, distilled:

• The document is legally bound to its format. Contracts, signed forms, and executed agreements must stay PDFs. You cannot “publish the HTML version” of a wet-signed document.
• Fixed layout is the point. Financial disclosures, regulatory filings, and statements are designed page-by-page; reflow can change meaning.
• Archival. PDF/A exists so a document is self-contained and renders identically in decades — and a single file can be both PDF/A and PDF/UA, i.e. archival and accessibility-conformant (Text Control, on why PDF/UA + PDF/A-3a matter for accessibility, archiving, and legal compliance).
• High-volume transactional runs. Bank, insurance, and utility statements are generated as PDFs by the million; there’s a whole discipline built around tagging those at scale rather than rebuilding them as web pages.

Notably, even the HTML-first governments carve out exactly this territory. GOV.UK’s own 2018 update: “We are not suggesting there is no place for PDFs… when there’s a need for a static document to show what was said at a particular point in time. In these cases, publishers should continue to publish a PDF in addition to HTML.” The disagreement is narrower than the format war implies.

The catch nobody puts on the slide: format is downstream of structure

Here is the part both camps skip. Neither output is any better than the structure you recovered to produce it. The format is a serialization step. The hard problem is figuring out the reading order, which cells are headers, what’s a heading vs. bold text, and what an image is for. Get that wrong and both outputs fail — in mirror-image ways.

Naive PDF→HTML produces “div soup.” The dominant converters (pdf2htmlEX and the tools that wrap it, including “Save as Web Page”) were built to reproduce a printed page on screen. They emit a <canvas> or a stack of absolutely-positioned <div>s with text pinned to pixel coordinates. It looks identical and is technically HTML — and it’s often worse for a screen reader than the original PDF, because the visual layout now masquerades as structure with none of the semantics underneath. A converter that doesn’t understand the document just launders a bad reading order into a new format.

Auto-tagging in place has the identical failure mode. Adobe’s own developer documentation disclaims its Auto-Tag output: it “is not guaranteed to comply with… WCAG and PDF/UA, as you may need to perform further downstream remediation.” Recent HCI research on complex and multi-column layouts reaches the same conclusion (a 2025 ACM CHI paper, arXiv:2503.22216): reading order, heading levels, table relationships, and meaningful alt text still need a human.

This isn’t a vibe. It’s measured:

• Automated checkers detect only ~25–30% of issues. The UW PDF Accessibility Benchmark (“Benchmarking PDF Accessibility Evaluation,” arXiv 2509.18965, ASSETS 2025) found rule-based tools “universally failed to identify semantically incorrect header-data relationships” even when they verified that headers were present. Presence is not quality. The paper’s conclusion is a hybrid of automated checks, LLM evaluation, and human review for the ambiguous cases.
• PDF/UA conformance has 87 software-checkable conditions, 47 that “usually require human judgment,” and 2 with no test — that’s the Matterhorn Protocol, written by the PDF Association itself (31 checkpoints, 136 failure conditions). The body that defends PDF accessibility is the same one telling you software can’t certify roughly a third of it.
• Even the PDF Association concedes that “by itself, conformity to PDF/UA does not necessarily ensure the accessibility of a document’s content.” Both camps, then, actually agree on the operational point: conformance is not the same as accessible, and a human still has to look.

So “HTML or remediated PDF?” is the last decision, not the first. The first decision is whether your pipeline actually recovered the document’s structure — because if it didn’t, you’re just choosing which flavor of broken to ship.

What the evidence says

A few numbers worth having in front of you. (There is no credible single market-size figure for document remediation — claims in both directions fall apart on inspection — so treat any “$X billion TAM” you’re quoted with suspicion.)

Claim	What’s documented	Source
Baseline inaccessibility	74.9% of ~20k scholarly PDFs meet zero of six criteria; <3.2% meet all.	arXiv 2410.03022 (UW, ASSETS’24)
Automation ceiling	Checkers catch ~25–30% of issues; 47 of 136 PDF/UA conditions need human judgment.	arXiv 2509.18965; Matterhorn Protocol
Manual remediation cost	~$4–$25/page typical; one published rate card is $7.50–$11.50/page (“an 80-page PDF ≈ $400”). Automated/hybrid: $0.30–$2/page.	Accessible.org, Equidox pricing
Backlog scale	Denver: ~2 web staff for ~12,000 PDFs. Iowa State: ~500,000 web PDFs, contracts at $100K–$150K/yr — the institution’s own verdict: “the math doesn’t work.”	Inside Iowa State (Apr 2026)

And the regulation forcing the question:

• ADA Title II (US). DOJ’s 2024 final rule adopts WCAG 2.1 AA for state and local government web content — and explicitly defines a PDF posted to a site as “web content” (a “conventional electronic document”), so the same conformance target applies whether you ship HTML or a tagged PDF. Format is an implementation choice, not a compliance loophole. Deadlines were extended by a DOJ Interim Final Rule (20 Apr 2026): population 50,000+ now 26 Apr 2027, under 50,000 / special districts now 26 Apr 2028 — but it’s an interim rule still open to comment, and DOJ told entities to “keep going.” (ADA web rule · extension IFR)
• Section 508 (US federal) incorporates WCAG by reference via the Access Board’s ICT standards, and procurement can reject or charge back non-conforming deliverables.
• EU. The European Accessibility Act and the harmonized standard EN 301 549 point the same direction — a format-agnostic conformance outcome.

None of these say “convert to HTML” or “keep it a PDF.” They specify an outcome and leave the format to you. Which is exactly why the decision should be per-document.

A decision framework

Stop arguing format in the abstract. Sort each document by what binds it.

Document type	Bound to PDF?	Default path
Web page, news post, FAQ, policy explainer	No — it was only ever a PDF by habit	Convert to semantic HTML. It’s web content in a PDF costume.
Syllabus, handbook, brochure, county agenda, report	Mostly no	HTML-first for the canonical version; keep a tagged PDF only if a real print/download need exists.
Contract, signed form, executed agreement	Yes — legal/signature	Remediate the PDF. The file is the record.
Financial filing, disclosure with mandated layout	Yes — regulatory	Remediate the PDF. Layout is legally load-bearing.
Archival document (PDF/A)	Yes — preservation	Remediate the PDF (PDF/A + PDF/UA in one file).
High-volume transactional statement (bank/utility)	Usually — generated as PDF	Remediate in the generation pipeline, or emit accessible HTML and a tagged PDF from one source.

The pattern: informational, web-destined content → HTML-first. Legally or operationally PDF-bound content → remediate in place — and where feasible, pair the PDF with an HTML alternative, exactly as GOV.UK recommends. Most real backlogs are a mix, which is why “always convert” and “always remediate” both lose to “triage, then route.” Whichever path a document takes, the ~47/136 human-judgment conditions still need a person.

Where okraPDF lands

We don’t think the format is the moat — and you shouldn’t have to pick a religion, or maintain two documents by hand. The reusable asset is the structure recovered once, with evidence: a bbox-cited node graph that records what’s on the page, where, and how confident we are. A PDF and an accessible HTML version are just two renders of that one structure — not two files you keep in sync by hand.

That’s what makes the whole HTML-vs-remediation argument dissolve. Give us the PDF; we generate the accessible, semantic HTML twin — built from the recovered structure, not pixel-positioned div soup — and bind it to that exact PDF version. Change the PDF, the HTML revalidates and follows it, so your “accessible alternative” never quietly drifts out of date. Then you publish whatever your compliance situation needs:

• HTML only, when the content should never have been a PDF (web pages, FAQs, policies);
• the PDF plus its tracked HTML twin — exactly what GOV.UK tells you to do (“publish a PDF in addition to HTML”), but without needing the staff to maintain both by hand;
• an accessible, tagged PDF, when the file is legally or operationally bound to its format.

One source of truth, version-tracked, emitted to the format your auditor requires — not the one your ideology prefers. Every finding still points to a page region (page, bbox) so a reviewer can approve, reject, or fix it without rereading the document.

And we keep the claims honest with three tiers, because the human-judgment boundary is real and measured:

1. Audited — automated checks plus a bbox-cited evidence report.
2. Remediated — repaired output (tagged PDF and/or its accessible HTML twin) with a machine-validation summary.
3. Attested — human-reviewed output with procurement-ready evidence.

We avoid “certified” and “guaranteed compliant,” because 47 of those Matterhorn conditions are exactly the ones software can’t decide alone. The checker triages; the human attests.

TL;DR

• The format ships broken by default — 74.9% of PDFs meet zero accessibility criteria — so every camp has to do something.
• HTML-first is the right default for informational, web-destined content. GOV.UK, the UK ONS, the US GSA, and Nielsen Norman Group all say so — and they’re vendor-neutral.
• In-place remediation is right for legally or operationally PDF-bound documents — contracts, signed forms, filings, PDF/A archives, statements. PDF/UA is a real, achievable standard.
• Format is downstream of structure. Div-soup conversion and naive auto-tagging fail the same way: both serialize a reading order nobody verified. Checkers catch ~25–30% of issues; 47 of 136 PDF/UA conditions need a human.
• Decide per document, not per ideology, and route the human-judgment cases through review on either path.
• The most common real answer is both — a PDF of record paired with a tracked, accessible HTML twin, kept in sync from one source and published to your compliance need.

The cheapest mistake is choosing a format before you’ve recovered the structure. The next cheapest is claiming “compliant” when all you ran was a checker.

---

Further reading: Why GOV.UK content should be published in HTML and not PDF · Nielsen Norman Group — PDF: Still Unfit for Human Consumption · PDF Association — Busting the myth that PDF cannot be accessible · Matterhorn Protocol · UW PDF Accessibility Benchmark (arXiv 2509.18965) · The accessibility crisis in scholarly PDFs (arXiv 2410.03022) · DOJ ADA Title II web rule · OMB M-24-08 — federal HTML-default mandate · okraPDF: what ‘HTML’ should mean from a PDF API · how to use a PDF accessibility risk report