The Most Accessible Version of Your PDF Isn't a PDF - RipAI

Route: `/blog/most-accessible-version-of-your-pdf-isnt-a-pdf`
URL: https://rippdf.com/blog/most-accessible-version-of-your-pdf-isnt-a-pdf
Source file: `src/pages/blog/MostAccessiblePDFIsntAPDF.jsx`

Page Summary

Government guidance, screen reader surveys, and large-scale studies agree: HTML-first is the accessibility best practice. And the same reconstruction work buys your AI-readiness too.

Key Headings

H1: The Most Accessible Version of Your PDF Isn't a PDF
H2: Executive takeaway
H2: First, the honest concession: accessible PDFs are real
H2: Don't take a vendor's word for it - the consensus is already written down
H2: Why HTML wins: the format does the work
H2: The catch: the guidance assumes you have the source
H2: Beyond conversion: what an accessibility-ready HTML layer actually needs
H2: Two mandates, one workload: combine the budgets
H2: What this doesn't do - on purpose
H2: The best practice, restated
H2: Next step
H3: Sources
H3: In this article
H3: Key stats
H3: See it on your own PDFs?

Page Content Extract

Accessibility | HTML-First
The Most Accessible Version of Your PDF Isn't a PDF
For document content meant to be read online, HTML-first is the best practice - not PDF-never.
Government guidance, screen reader surveys, and large-scale studies agree: HTML-first is the accessibility best practice. And the same reconstruction work buys your AI-readiness too.
Accessibility
By John Austin
Jun 11, 2026
Ask anyone who owns an accessibility program about their PDF backlog and you'll get a number with too many zeros in it.
It's probably still an undercount. Allyant's cross-industry PDF Accessibility Index tested more than 15 million pages against WCAG 2.2 and found nearly 95% of PDFs inaccessible (
). Whatever your estate holds, assume nearly all of it is in scope.
of PDFs inaccessible
More than 15 million pages tested against WCAG 2.2.
Source: Allyant PDF Accessibility Index
Manual remediation economics - DigitalA11Y benchmarks
Simple-to-moderate documents
per page ceiling
Complex documents
min per page
Specialist labor
And here's the part that should bother you more than the cost: after all that labor, what you get back is a
more accessible fixed-layout page
. You've paid expert rates to retrofit semantics onto a format that was designed to lock them out.
There's a better default, and it isn't a niche opinion anymore. For document content meant to be read online, the accessibility best practice is to publish semantic HTML as the primary format - and treat in-place PDF remediation as the exception, not the program.
In this article
Executive takeaway
First, the honest concession: accessible PDFs are real
PDF/UA exists. A properly tagged PDF with a high-quality tag tree, correct reading order, and reviewed alt text works in modern screen readers. And some documents genuinely must remain PDFs - signed instruments, sealed records, regulated filings, anything where the page itself is the authoritative artifact, plus content intended for print or offline download.
So this isn't an anti-PDF argument. The position worth defending is "HTML-first," not "PDF-never."
But hold the concession to its own standard. WebAIM is blunt that an untagged PDF is not considered accessible at all - PDF accessibility lives or dies on a separate tag layer added to the format (
). Even W3C, in publishing its PDF techniques for WCAG, cautions that their existence does not imply PDF can be used in all situations to create conforming content (
conform. The format just makes you fight for it, one document at a time, forever.
The real issue is simpler than the standards debate: PDFs are routinely treated as web content when they are actually fixed-layout documents. For online reading, that's a category error - and your users are paying for it.
Don't take a vendor's word for it - the consensus is already written down
Government digital services have already ruled.
GOV.UK's accessible-documents guidance states it outright:
"HTML is the most accessible format for publishing documents. It should be your first choice whenever possible"
prioritize HTML and use PDFs only when necessary
Section508.gov
). These aren't vendor opinions. They're the operating policy of organizations that manage document accessibility at national scale.
The people who rely on assistive technology agree.
In WebAIM's screen reader user surveys, 75.1% of respondents said PDFs were very or somewhat likely to pose significant accessibility issues (
). Two years later, asked which document format they found
accessible, only 12.9% chose PDF - 68.9% chose Word (
). When fewer than one in seven of your actual assistive-technology users picks your default publishing format, the format is the finding.
The user verdict - WebAIM screen reader surveys
say PDFs are very or somewhat likely to pose significant accessibility issues.
WebAIM Survey #8
pick PDF as the
accessible format - versus 68.9% who pick Word.
WebAIM Survey #9
And the estate-level data is brutal.
A 2024 study of 20,000 scholarly PDFs found fewer than 3.2% satisfied all tested accessibility criteria - 74.9% failed every single one (
). A 2026 study of 100,000 PDFs across 1,000 open repositories found 0.3% passed all automated tests (
Sage Journals
). Luxembourg's public-sector audit of 25,398 PDFs on its highest-traffic government sites found 59% untagged - including 52% of forms, the documents citizens most need to use (
accessibilite.public.lu
). Inaccessible PDFs are not edge cases. They are the statistical norm of every estate measured - and notice that these independent academic and government audits land in the same place as the vendor index this post opened with. When the people selling remediation and the people studying it for free agree on the number, believe the number.
passed all tested criteria across 20,000 scholarly PDFs.
passed all automated tests across 100,000 repository PDFs.
Sage Journals, 2026
untagged across 25,398 government PDFs - 52% of forms.
Luxembourg audit, 2023
Why HTML wins: the format does the work
The mechanics behind that consensus come down to where each format starts from.
HTML's semantics are native.
Headings, landmarks, lists, tables, forms, and language attributes are part of the web platform itself, exposed directly to browsers and assistive technology - with built-in accessibility behavior like keyboard support for native controls (
). PDF requires that semantic layer to be added, verified, and maintained as tags - invisible to everyone except the specialists qualified to audit them.
Reflow is an HTML property and a PDF fight.
WCAG 2.1's reflow criterion exists because two-dimensional scrolling makes users lose their place and adds physical and cognitive load (
). Responsive HTML reflows across zoom levels, mobile screens, reader modes, and user text-spacing settings. Fixed PDF pages generally demand zooming plus scrolling in both directions - and resist the user's own colour and text-size settings (
Usability research says the same thing accessibility research does.
Nielsen Norman Group has spent twenty years documenting that PDFs are unfit for online reading - slower task completion, broken navigation, user frustration - and recommends reserving PDF for documents users will print (
). Accessibility and usability are the same curve: a document can pass a checker and still defeat its reader.
And the operations favor HTML.
An HTML page has one canonical URL, gets edited in place, shows up in analytics, and can be audited. A remediated PDF gets re-remediated on every revision, and once downloaded it goes dark - no usage data, no update path, no governance (
So the best-practice model is settled:
Source content
Structured HTML page
Optional accessible PDF download
Not print document -> PDF -> uploaded as the primary digital experience.
The catch: the guidance assumes you have the source
Read the GOV.UK guidance closely and you'll find the quiet dependency: to create an HTML page from an existing PDF, you need the source document (
Now look at your estate. The policy library built over fifteen years. The reports inherited through reorganizations. The vendor deliverables, the scanned records, the documents whose authors retired. For a large share of any real PDF estate, the source is gone - the PDF
That's why "convert it to HTML" has stayed a best practice more preached than practiced. The cost was never saving an
file. The cost is reconstructing the meaning the PDF lost: the real heading hierarchy (not bold-text-as-heading), the reading order across multi-column layouts, the table structure with cell relationships intact, the image context, the document's identity. Do that by hand and you've recreated the same per-page labor you were trying to escape. Run it through a naive converter and you get a wall of styled
s in scrambled order - which reads as progress in a status report and as nothing at all in a screen reader. The practitioner guidance is explicit on this point: don't merely export PDF to HTML - rebuild the document as semantic HTML, preserving headings, reading order, lists, table structure, alt text, and language.
That reconstruction step is the actual product. It's what RipAI was built to automate - directly from the PDF, no source files required.
Beyond conversion: what an accessibility-ready HTML layer actually needs
Accessibility HTML
Then three things in the bundle go further than any conversion - and they're the difference between "we made an HTML file" and "we made the content usable."
why Markdown alone isn't an AI knowledge strategy
Two mandates, one workload: combine the budgets
Now the part that changes the funding conversation.
Write down what WCAG remediation actually requires of a document. Now write down what AI-readiness requires before a copilot, search index, or RAG pipeline can trust that same document. Set them side by side:
WCAG remediation requires
AI-readiness requires
It's the same list.
The broken structure that defeats a screen reader is the broken structure that defeats crawlers, reader modes, and AI answer engines. A document assistive technology can't navigate is a document AI systems can't cite.
Yet most organizations are funding these as two separate programs - an accessibility remediation effort in the compliance office, a document AI-readiness effort under the CIO - each paying its own vendors to perform the same upstream reconstruction on the same files. Run separately, the workloads are largely redundant. You are buying the same structural engineering twice and calling it two initiatives.
Two mandates, often two budgets - one piece of work.
What this doesn't do - on purpose
RipAI creates accessibility-structured HTML, visible context, and review signals. It does not certify anything. Final WCAG, Section 508, or PDF/UA conformance remains your organization's determination, made through validation, assistive-technology testing, and human sign-off. Be suspicious of any tool that promises conformance in one click - that's not a shortcut, it's audit risk with a progress bar.
What automation should do is exactly this: compress the structural reconstruction that consumes most of the labor, and hand your experts a prioritized review queue instead of a blank backlog.
The best practice, restated
The most accessible version of your PDF isn't a PDF. It's the HTML companion standing next to it.
RipAI turns PDF estates into accessibility-ready HTML companions and AI-ready knowledge assets from the same reconstruction - structure rebuilt directly from the PDF, context made visible, review signals built in, governed at batch scale on a local desktop. Bring a sample of your public-facing PDFs to a guided assessment and see the reconstructed structure, context panel, and review signals on your own documents.
Book a Guided Assessment
Explore Accessibility HTML
DigitalA11Y, PDF Remediation Pricing Guide
GOV.UK, "Publishing accessible documents"
Section508.gov, "Create Accessible PDFs"
Government Digital Service (UK), "Why GOV.UK content should be published in HTML and not PDF" (July 2018)
WebAIM, Screen Reader User Survey #8 (2019)
WebAIM, Screen Reader User Survey #9 (2021)
WebAIM, "PDF Accessibility - Defining PDF Accessibility"
W3C, PDF Techniques for WCAG 2.0 (applicability caveat)
W3C, Understanding SC 1.4.10: Reflow
MDN, "HTML: A good basis for accessibility"
"Uncovering the New Accessibility Crisis in Scholarly PDFs" (arXiv, 2024 - 20,000 PDFs)
Rożej, Skonieczny & Koperwas, "PDF accessibility in open repositories: A large-scale automated assessment" (Journal of Information Science, 2026 - 100,000 PDFs)
Luxembourg digital accessibility portal, public-sector PDF audit (2023 - 25,398 PDFs)
Nielsen Norman Group, "PDF: Still Unfit for Human Consumption, 20 Years Later" (2020)
Nielsen Norman Group, "Avoid PDF for On-Screen Reading"
Allyant, PDF Accessibility Index 2025-2026 Benchmark Report (15M+ pages tested against WCAG 2.2)
Automated-remediation effort reduction range (60-90%, conservative middle 60-70%): convergent industry deployments documented in claims registry §A (Apex CoVantage, PDFix/Slovak Technical University, Continual Engine, ADAPT AI, State of New Mexico/Adobe), web-verified 2026-05-30.
of PDFs inaccessible (Allyant PDF Accessibility Index).
$150 per page
ceiling for complex remediation (DigitalA11Y).
One reconstruction,
two deliverable families.
See it on your own PDFs?
Bring a sample of your public-facing PDFs and see the reconstructed structure, context panel, and review signals.
Accessible PDFs are real
The consensus is written down
Why HTML wins
The catch: you need the source
Beyond conversion
Two mandates, one workload
What this doesn't do
A visible contextual layer
Review signals, not compliance theater
Each export ships with an audit file that flags what still needs human judgment: missing alt text, generic alt text rejected against a blocklist, heading-level jumps, complex tables, structural risks, and overall publishing readiness. Your specialists stop spending hours discovering what's wrong and spend them deciding what's right - the judgment work only they can do.
Estate-scale governance
This is built for thousands of documents, not one-off remediation jobs: governed batch processing, a manifest with document identity and provenance, and quality reports that tell you which documents to review first - so the backlog becomes a prioritized queue instead of a guess. It runs on the desktop, where your documents already live. Nothing leaves your environment.

Canonical References

https://rippdf.com/ai/blog.md