Here’s a small experiment we run for new clients. We take one of their PDFs, usually something important, like a benefits guide or an application form, and we open it with a screen reader, the software blind visitors use to have documents read aloud. Then we press play. More often than not, the screen reader says one word: “Blank.”

The document isn’t blank. It’s forty pages of carefully written, professionally designed content. But to the software a blind person depends on, it may as well be an empty envelope. Every word your team wrote, every table your designer laid out, unreadable. And nobody ever complained, because the people it locks out simply closed the file and left.

Fixing that is called PDF remediation, and it’s one of the most misunderstood services we offer, mostly because the work is invisible. When we hand a document back, it looks exactly the same. So in this article we’re opening the workshop doors: here is our entire manual PDF remediation process, step by step, in plain English. If you’d rather see it in action first, you can send us a document for a free review and we’ll show you exactly what a screen reader hears, before and after.

What “Remediation” Actually Means (No Jargon, Promise)

A PDF is really two documents in one. There’s the visible layer, the words, images, and layout you see on screen. And there’s a hidden layer of labels underneath, called tags, that tells assistive software what everything is: this is a heading, this is a paragraph, this is a table with three columns, read this part first and that part second.

Sighted readers never notice the hidden layer, because our eyes do that work automatically, we see big bold text and know it’s a heading. A screen reader can’t see. It depends entirely on the tags. When they’re missing or wrong, the visible document and the spoken document become two completely different experiences:

Remediation is the work of building that hidden layer correctly, rebuilding the document’s spoken skeleton so it says what the page shows. Done right, it satisfies the standards that matter (WCAG, Section 508, PDF/UA) and, far more importantly, it means a real person can actually read your document. If you’re curious where one of your own files stands, our PDF accessibility workspace will check it and explain the results in plain language.

Why We Do This by Hand

Some tools promise one-click “auto-tagging.” We’ve tested them all, and here’s the honest verdict: they’re guessing. Software can detect that text is large and bold and guess it’s a heading. It cannot know that your two-column newsletter should be read left column first, that the decorative swoosh on page three means nothing, or that the table on page twelve has merged header cells that need untangling. Auto-tagged documents routinely announce headings that aren’t headings, read columns in the wrong order, and describe images as “graphic” forty times in a row.

The result is a document that passes a checker and still makes no sense to a human ear. That gap, between technically tagged and actually usable, is exactly where lawsuits and complaints live. It’s why every document we remediate is done by a person, tag by tag, page by page. Slower? Yes. But it’s the difference between a document that has tags and a document that works.

Step 1: We Collect and Prioritize Your Documents

Most organizations don’t have one PDF, they have hundreds, sometimes thousands, scattered across their website and file servers. Trying to fix everything at once is a recipe for spending a lot of money on documents nobody opens. So we start with triage.

Together we figure out which documents actually matter: the ones visitors download most, the ones required to apply for something or receive a service, the ones with legal weight, and the ones that will stay in circulation for years. Those go first. A flyer for an event that happened in 2019 probably doesn’t need remediation, it needs deleting. If you don’t know what PDFs are even on your site, our sitewide PDF workspace can crawl your website and build the inventory for you.

Step 2: We Inspect Each Document, by Hand

Before fixing anything, a specialist opens each document and takes stock. Is there any tag structure at all, or are we starting from zero? Is the text real, selectable text, or is the whole thing a scanned photograph of paper, which is a different job entirely? How many tables, and how gnarly are they? Are there form fields to fill in? Charts that need describing? A hundred footnotes?

This inspection matters for two reasons. First, it tells us exactly what the document needs, so nobody pays for guesswork. Second, it catches the surprises early, the “simple brochure” that turns out to contain a 14-page data table, or the form that was built as a flat picture of a form, with nothing to actually type into. You get a clear picture of the work before the work begins.

Step 3: We Rebuild the Structure, Tag by Tag

Now the core of the craft. A specialist works through the document and rebuilds its hidden layer by hand, deciding (with human judgment) what every single element is and how it should be announced:

• Reading order. We set the exact sequence a screen reader follows, so a two-column layout reads like an article instead of a shuffled deck, and so sidebars and pull quotes stop interrupting sentences mid-thought.
• Real headings. Big bold text becomes an actual tagged heading, in a logical outline. This is huge: screen reader users skim documents by jumping heading to heading, exactly like sighted readers skim a page. No headings, no skimming, just forty pages read straight through.
• Alt text for images. Every meaningful image gets a short written description of what matters: not “chart,” but what the chart actually shows. Decorative flourishes get marked as artifacts so the screen reader skips them silently instead of announcing junk.
• Lists tagged as lists. So “Step 1 of 6” is announced as step one of six, context a visual reader gets for free.

Step 4: Tables, Forms, and Links, the Hard Parts

Some parts of a PDF are so consistently broken that they get their own dedicated pass. These are the pieces where automated tools fail hardest and where hand work earns its keep:

• Tables. A properly tagged table announces its headers as you move through it: “Plan: Silver. Monthly cost: $210.” A badly tagged one reads out a stream of disconnected numbers, imagine your rate sheet read aloud with all the labels removed. We tag every header, every cell relationship, and untangle the merged and nested cells that trip software up.
• Forms. Every field gets a label that says what it is (“Date of birth,” not “text field”), a sensible tab order so keyboard users move through it logically, and clear required-field cues. A form a blind visitor can’t fill out isn’t a form, it’s a wall.
• Links. “Click here” becomes a link that says where it goes, because screen reader users often pull up a list of a document’s links out of context, and a list of ten “click here”s is useless.

Step 5: The Finishing Touches Nobody Sees

Then come the small settings that quietly decide how a document behaves. We give the file a real title, so a screen reader announces “2026 Employee Benefits Guide” instead of “final_v3_FINAL.pdf.” We set the document language, so the software reads English text with English pronunciation instead of mangling every word. We check that text can reflow and enlarge for low-vision readers, that color isn’t carrying meaning by itself, and that nothing in the document’s security settings blocks assistive technology from reading it at all, a surprisingly common and surprisingly cruel mistake.

Step 6: We Test It the Way Your Readers Will, by Ear

When the rebuilding is done, we don’t just run a checker and call it a day, although we do run the checkers, and the document has to pass them. The test that actually matters comes after: a specialist turns on a screen reader and listens to the entire document, start to finish.

Does the reading order make sense out loud? Do the headings tell a clear story when you jump between them? Does the table actually make sense by ear, or just on paper? Does the form announce each field clearly as you tab through it? “Does this make sense when you hear it?” is a question no software can answer — and it’s the whole point of the work. If something sounds wrong, it goes back for fixing, and then it gets tested again. Nothing leaves until it reads cleanly.

Step 7: You Get Your Documents Back, With Proof

Finally, you get your files back, visually identical to the ones you sent, same fonts, same layout, same branding. The difference is all in the layer you can’t see. Along with the files, we document what was done, so you have a record showing the work: useful for your own peace of mind, essential if you ever need to demonstrate compliance to a regulator, a client, or a court.

And because accessibility claims are easy to make and hard to verify, we encourage every client to spot-check us: open the finished document with a free screen reader, or drop it into any checker you like. The work should hold up to anyone’s inspection. That’s what “defensible” means.

What We Need From You (Very Little)

The process is deliberately light on your end: send us the documents, tell us which ones matter most, and answer the occasional question, usually about what an image should convey or which order a tricky layout should read in, because you know your content better than anyone. If you have the original source files (the Word document or InDesign file a PDF was made from), great, they can help — but they’re not required. We work with what you have, including PDFs whose sources vanished with an employee three jobs ago.

After the Backlog: Keeping New Documents Accessible

Remediation fixes the documents you have. But your team will keep making new ones, and every new untagged PDF starts the problem over. That’s why the long-term win is pairing remediation with a little prevention: building accessibility habits into how your documents get made in the first place, real heading styles in Word, alt text written at creation time, tables built as tables instead of pictures of tables. We offer team training for exactly this, and clients who do both tell us the same thing: fixing documents is a project, but making accessible documents is just a habit.

Frequently Asked Questions

Can you fix scanned PDFs?

Yes. A scanned PDF is a photograph of paper, there’s no actual text in it for a screen reader to find, which is why scans are the documents most likely to read as “blank.” We first convert the images into real, verified text (and hand-correct what the conversion gets wrong), then remediate the document like any other. It’s more work than a born-digital PDF, but it’s routine work for us.

Can’t we just use an auto-tagging tool ourselves?

You can, and for a very simple document it may get you partway there. Just know what you’re getting: auto-taggers guess, and their guesses fail most on exactly the content that matters, tables, forms, multi-column layouts, and images. The risky part is that an auto-tagged document often passes automated checkers while still being unusable by ear, which gives a false sense of being covered. If you try it, have someone listen to the result with a screen reader before you trust it.

Will remediation change how our documents look?

No. All the work happens in the hidden tag layer, so the visual document, layout, fonts, colors, branding, stays exactly as your designer intended. The only exceptions are genuine visual accessibility problems we flag along the way, like text whose contrast is too low to read; we’ll point those out, and fixing them is your call.

Hear the Difference on One of Your Own Documents

The fastest way to understand this work is to experience it on a file you know. Request a free review and send us a PDF, we’ll assess it by hand and tell you plainly what a screen reader user experiences today and what it would take to fix. Our pricing is published, and our manual PDF remediation service handles everything from a single urgent form to a backlog of thousands. Your documents already look right. Let’s make them work right, too.