How To
Two things live on this page: a quick walkthrough of using poofPDF itself, and a much bigger, tool-agnostic guide to making any document accessible — because the checklist matters a lot more than which product you run it through.
Using poofPDF1. Upload a PDF
Drop a PDF onto the dropzone on the homepage, or click choose a file. Everything below runs in your own browser — your file isn't sent anywhere first.
Illustrative mockup of the upload step — not an exact screenshot of the current interface.
2. Read your checklist
The Overview tab groups every automated finding into categories (document basics, structure & navigation, images, tables & lists, color & contrast, links & forms) with a pass/warn/fail status and a confidence level, so you can triage the high-confidence items first. Dig deeper in the Metadata, Headings & Structure, Images & Alt Text, and Tables tabs.
Illustrative mockup of a grouped checklist row — not an exact screenshot of the current interface.
3. Fix contrast & links
The Color Contrast & Links tab flags text/background combinations under WCAG's 4.5:1 minimum and links identified by color alone. This is the one tab where an automated fix actually repaints pixels rather than just adding metadata, so it asks for an explicit checkbox acknowledgement before it's included in your export. We built a genuinely thorough checking and verification pipeline here — including a final pass against the exact bytes you download — but nobody's perfect, including us, so always spot-check the result.
4. Export a fixed PDF
The Export tab offers two strategies:
Illustrative mockup of the export options — not an exact screenshot of the current interface.
Patch original PDF (default, recommended for most files) keeps your file byte-for-byte identical in appearance. Rebuild & Tag discards the original and redraws every page from this tool's own analysis to reconstruct structure that cannot be repaired in place, at the risk of shifting fonts or spacing. Its completeness depends on the content poofPDF can successfully analyze — use it only if a file's existing tagging is pervasively broken.
Troubleshooting
My exported PDF looks slightly different than I expected.
If you used Patch original PDF without any opt-in contrast/link fixes, appearance should be byte-for-byte identical — check whether you accidentally applied the contrast fix, or try Rebuild & Tag only if the patched version still isn't reading correctly in a real screen reader.
The checklist still shows warnings after I fixed things.
Some checks (reading order, mixed-language passages, use of color) are flagged low confidence because they genuinely require human judgment — they may never fully clear, and that's expected. Re-upload your corrected file to refresh high-confidence checks like headings, alt text, and contrast.
Why does poofPDF say some fixes are "opt-in"?
Anything that changes how your document actually looks (contrast repainting, link underlines) is opt-in and requires an explicit checkbox. Everything else (headings, alt text structure, table/list tagging) is metadata-only and never changes appearance, so it doesn't need the same guardrail.
Core accessibility concepts (and how they map to what we check)
None of this is specific to poofPDF or even to PDFs — the same handful of ideas underpin accessible web pages, Word documents, and presentations. Here's the short version of each, tied back to what our checklist reports:
Structure & headings
A document's headings should form a real, nested outline (H1 → H2 → H3, no skipped levels) so a screen reader user can jump between sections the way a sighted reader skims a page. This underlies WCAG 1.3.1 Info and Relationships and 2.4.6 Headings and Labels — both appear directly in our Overview and Headings & Structure tabs.
Alternative text
Every meaningful image needs a short, accurate text description; purely decorative images should be marked as such so assistive technology skips them instead of announcing noise. This is WCAG 1.1.1 Non-text Content, covered by our Images & Alt Text tab.
Color & contrast
Text needs enough contrast against its background to be legible for low-vision readers (WCAG 1.4.3, generally 4.5:1), and information should never be conveyed by color alone (WCAG 1.4.1) — a required field or a link needs a non-color cue too, like an asterisk or an underline.
Tables, lists & forms
Data tables need real header cells (with a declared /Scope) so a screen reader can
announce "Column: Revenue, Row: Q3" instead of reading a wall of numbers. Bullet/numbered content
should be tagged as a real list, not just typed symbols. Fillable forms need every field labeled
with meaningful text, not just a bare, unlabeled box.
Reading order
The order assistive technology encounters content should match the logical reading order a sighted person would follow — this is frequently wrong in multi-column layouts, sidebars, and pull-quotes, and it's one of the hardest things to check automatically. Always spot-check this one by hand.
Other tools worth using
We don't care who you use — we're about making the internet accessible for everyone. No single checker, including ours, catches everything, and a second opinion is cheap insurance. Some worth adding to your workflow:
- Adobe Acrobat's built-in Accessibility Checker — the closest thing to an industry-standard PDF/UA validator, and worth running on any PDF before it ships.
- veraPDF's PDF/UA validator — a major open-source standards checker that reports exact PDF/UA rules. For a demanding, public test file, download the official IRS Form 1040 PDF and compare the original with the remediated copy. A lower finding count is useful evidence, but it is not a substitute for keyboard and screen-reader testing.
- Microsoft's Accessibility Checker in Word and PowerPoint — if your PDF started life as a Word doc or slide deck, fix what it flags before you export to PDF; problems caught there are far easier to fix at the source.
- A real screen reader — NVDA (Windows), VoiceOver (built into macOS/iOS), or JAWS. Nothing substitutes for actually listening to your document the way a real user would.
- Your local AI assistant — a general-purpose AI can be a genuinely useful second opinion for drafting alt text, spotting an awkward reading order, or explaining why a specific WCAG criterion applies to your document. Treat it the same way as any other tool here: helpful, not infallible.
- Deque University & WebAIM — dequeuniversity.com and webaim.org are two of the most respected, vendor-neutral accessibility education resources online, useful well beyond PDFs.
Check your work in more than one place, and when tools disagree, believe the one that's closer to how a real assistive-technology user will actually experience the document.
Why poofPDF, with no secrets about it
We'd rather earn your confidence with specifics than a slogan. As currently provided:
- Analysis and export both run entirely client-side for the browser-based tool — your file is parsed and rewritten in your own browser, never uploaded to a server first. The AI-assist feature works differently — see our Privacy Policy for exactly what that does and doesn't send.
- The default Patch original PDF path is built to be byte-for-byte identical in appearance to your source file — it only ever adds or repairs structure metadata, and only where it can be safely, surgically matched to what already exists.
- Contrast fixes run through a multi-pass verification that re-audits the exact final bytes of the file you're about to download — not just the fix logic in isolation — before it ever reaches your downloads folder.
- The checklist itself covers 15+ distinct WCAG 2.0 / PDF-tagging criteria, each with its own confidence rating, so you always know how much to trust a given result.
- The tool is built around transparent limits and repeatable checks. We think that combination is a fair basis for you to trust us with your documents.