You've seen the pitch. It's everywhere right now: just drag your inaccessible PDF into an AI tool, ask it to "make this accessible," and walk away with a compliant document. No screen reader testing, no tagging software, no consultant invoice. Just a prompt and a few seconds of processing.
It sounds too good to be true, so we decided to find out whether it actually is. Instead of speculating, we built a real invoice PDF exactly the way a typical export-to-PDF button in an accounting or design tool builds one: text drawn onto the page at absolute positions, with zero structure tags underneath it. Then we handed it to an AI model and watched what happened, step by step, with no cherry-picking.
The Stat: In our own real test, an AI model correctly reconstructed the true visual reading order from a genuinely untagged invoice PDF and drafted a clean accessible HTML replacement, but it could not touch the original PDF's actual tag structure at all, confirmed by checking the file for a real PDF/UA StructTreeRoot (there was none).
(Source: our own real, reproducible test, detailed in the article below)
The setup: a PDF built to fail, on purpose
We didn't grab some old scanned document off the internet. We built the invoice ourselves, using standard PDF-generation code, the same way a typical "export to PDF" feature in an accounting tool or design app actually works under the hood. Text gets drawn onto the page at absolute x/y coordinates. Nothing in the file says "this is a heading," "this is a table," or "this is the total due." It's just shapes and glyphs positioned on a canvas.
This matters because it's the single biggest compliance blind spot most teams have. A PDF can look perfectly normal to a sighted person and still be completely unreadable to someone using a screen reader, because the file has no idea what order things are supposed to be read in.
We confirmed this programmatically before touching any AI. The file had zero tag structure, no StructTreeRoot, meaning no PDF/UA tagging existed anywhere in the document. Then we extracted the raw text and looked at the order it came out in. It matched the PDF's internal content-stream order (the order shapes were drawn onto the page), not the order a human eye would actually read them. The total-due amount showed up in the extracted text before the line-item table it's supposed to summarize, purely because whoever built the original file happened to draw that box first.
That's the real-world failure mode. Not "missing alt text" in the abstract. An actual document where the numbers come out of order the moment anything but human eyes touches it.
What we actually asked the AI to do
We took that extracted, scrambled text and gave it to an AI model with one instruction: produce a properly tagged, accessible HTML replacement suitable for someone rebuilding this as a real accessible document.
We're calling it "an AI model" deliberately and not naming a specific vendor product, because this was our own small, reproducible internal test, not a formal industry benchmark. We were grading the output on three things: did it preserve or correct the true visual reading order versus the scrambled extraction order it was given, did it use real semantic table markup with actual column headers, and did it honestly flag anything it couldn't verify or fix directly.
Here's what happened, plainly, with no rounding up.
What the AI actually got right
The output correctly reconstructed the visual reading order. Line items came first, the total came after, exactly as a sighted reader would expect, even though the AI was only ever given the scrambled content-stream order to work from. That's a genuinely useful reversal, and it's not a trivial one. Figuring out "the total belongs after the table it totals" from disordered text takes real inference.
It also used a real semantic HTML table, with proper column headers, not just visually-aligned text pretending to be a table. That's the difference between something a screen reader can actually navigate row by row and something that just looks like a grid.
And it did something we didn't prompt for: when it added placeholder alt text for the logo mark, it explicitly flagged that it couldn't verify what the logo actually depicted, since it had only received extracted text, not the image itself. That's an honest limitation being surfaced unprompted, which is exactly the kind of behavior you want from a tool making claims about accessibility.
What the AI could not do, at all
Here's the part the "just run it through AI" pitch skips over. The AI could not touch or repair the original PDF's actual internal tag structure. Not partially, not messily. Not at all. It has no mechanism to reach into a PDF and edit its PDF/UA tags directly from extracted text. All it can do is draft a brand-new replacement document from scratch.
That's a meaningfully different thing than "fixing your PDF." The original file, the one your accounting system actually generates and emails to customers every day, is completely untouched by this process. What you get is a good draft of a replacement, not a repaired original.
The honest verdict
AI genuinely helps with the drafting and reading-order half of PDF remediation. That part is real, it's useful, and it's fast, going from a scrambled extraction to a correctly-ordered, properly-tabled draft in a fraction of the time it would take a person working manually.
But it does not close the gap by itself. Someone still has to take that draft and make a decision: either rebuild the actual PDF with real tags using proper remediation tools, or make the accessible HTML version the actual source of truth going forward instead of the PDF. The AI output is a draft, not a fix. "AI fixes your PDF" oversells what happens. "AI drafts your replacement in minutes instead of hours" is the honest version, and it's still a genuinely good deal if you use it that way.
If you want to see whether a document counts as properly tagged in the first place, W3C's PDF techniques for WCAG lay out what real tagging looks like, and a tool like the PDF Accessibility Checker (PAC) will tell you definitively whether a given file has that structure or not, the same way we checked ours.
If your workflow still relies on hand-fixing tags one PDF at a time, our free-tool walkthrough for fixing PDF accessibility without Acrobat Pro covers the manual side of this. This article is about what AI can and can't do on top of that; it's a different problem than the free-tool how-to, but the two fit together.
What this means for your actual documents
If your PDFs come out of an export button the way ours did, an AI model can genuinely help you draft a clean, correctly-ordered, properly-tabled replacement fast. That's real value, not hype. Just don't mistake a good draft for a fixed original. The file your customers already have in their inbox needs its own remediation path, or it needs to stop being the canonical version.
If you're not sure how many of your own PDFs, or pages, have this exact problem hiding in them, AccessRadar will scan your site and tell you honestly, not with a marketing gloss.
Want to talk through what a real remediation plan looks like for your specific documents, tags and all? Reach a person on our team directly at experts@wcag.world, or start with a scan at AccessRadar.