How to Redact a PDF Without Breaking Its Accessibility for Screen Readers

By the SladdPDF team · Published September 5, 2026 · Updated September 5, 2026

Secure redaction and document accessibility want opposite things from the same page. Redaction wants the underlying text gone so nobody can recover it. Accessibility wants the underlying text present, tagged and in the right reading order so a screen reader can speak it. Most redaction guides — this site's included — only ever optimize for the first goal. If the document you're redacting also needs to stay usable for a blind or low-vision reader, that gap is worth understanding before you export.

Key takeaways

A screen reader depends on a PDF's tag structure — headings, reading order, alt text — which the PDF/UA standard (ISO 14289) formally defines and WCAG 2.x requires for conforming content.
Rasterizing a page for secure redaction flattens it to a picture. That destroys the tag structure and the text layer completely, which is exactly what makes the redaction safe — and exactly what makes the page unreadable to a screen reader.
There is no setting that gives you both a rasterized, unrecoverable redaction and a fully tagged, screen-reader-navigable page. You have to choose per document, or produce two versions.
US state and local government sites and mobile apps must meet WCAG 2.1 AA under the ADA Title II rule, with compliance deadlines the Department of Justice pushed back a year, to April 26, 2027 (population 50,000+) and April 26, 2028 (smaller entities). EU public-sector sites and apps have been covered since 2018 under the Web Accessibility Directive.
When a document must be both redacted and accessible, the reliable pattern is two artifacts: a rasterized, secure PDF for anyone who doesn't need assistive technology, and a separately remediated, tagged version — or an accessible plain-text/HTML equivalent of the same redacted content — for anyone who does.

Redaction and accessibility pull in opposite directions

Every serious redaction guide converges on the same technical requirement: don't just cover the sensitive text, remove it, and prove it's gone by rasterizing the page so no extractable text layer survives underneath. That's the same advice this site gives for why a black box isn't real redaction and why rasterization is the gold standard for making sure it's not recoverable.

Document accessibility asks for the opposite. A screen reader, braille display or voice-control tool doesn't read pixels — it reads a text layer, walked in a defined order, through a structure that says which text is a heading, which is a table cell, and what an image is a picture of. Take that structure away and the page isn't just harder to read for assistive-technology users; it's unreadable. A rasterized page announces as either nothing at all, or — if it was re-OCR'd afterward — an unstructured wall of text with no headings, no reading order and no indication of what's a caption versus body copy.

Neither side of this trade-off is wrong. A document with a recoverable text layer is not securely redacted. A document with no text layer and no tags is not accessible. The failure mode is treating them as the same problem, applying one fix, and assuming it covers both.

What makes a PDF accessible in the first place

The feature that makes a PDF usable with assistive technology is called a tagged PDF: a parallel logical-structure tree layered over the visual page, marking up headings, paragraphs, lists, tables and figures, plus a defined reading order and alternative text for images. The international standard for what a fully conforming, accessible PDF must contain is PDF/UA — ISO 14289-1 — which builds on the tagged-PDF features already defined in the base PDF specification (ISO 32000) and is written to work alongside the W3C's Web Content Accessibility Guidelines (WCAG).

None of this is exotic or optional add-on metadata. It's the difference between a screen reader saying "Heading level 2, Section 3: Eligibility" and a screen reader saying nothing, or reading three unrelated columns of a table as one run-on sentence because there was never a defined reading order to follow.

What rasterizing a page does to that structure

Rasterization, the technique behind Secure-mode redaction, flattens a page to a fixed grid of pixels — effectively a photograph of the page. It has no concept of a heading, a table cell, or an image description, because it has no concept of text or structure at all anymore: it's a picture. That's precisely why it's the correct technique for redaction — there is no text layer left to extract, so there's nothing left for a copy-paste test or a PDF parser to recover from underneath a redaction box.

It's also precisely why it destroys accessibility outright. Running OCR over a rasterized page afterward can put words back onto the page, but OCR text is not the same as a tagged structure: it typically has no heading levels, no defined reading order across columns, no table semantics and no alt text for images, and it will happily "read" a redaction box as nothing at all rather than announcing "[redacted]" the way a properly tagged PDF can.

Rasterizing a page for secure redaction and making that same page PDF/UA-conformant are mutually exclusive operations on the same file. You cannot flatten the page to guarantee no text survives and also keep a tagged text layer for a screen reader to read — those are contradictory requirements on the same bytes. Pick one per document, or produce two.

Why this matters more in 2026

Redacted documents released by, or on behalf of, a government body increasingly carry an accessibility obligation on top of a disclosure obligation, and the compliance dates have moved closer even in the last few months:

Standard / rule	Who it binds	What it requires
WCAG 2.2 (W3C)	The baseline referenced by most accessibility law worldwide	Success criteria for perceivable, operable, understandable and robust content, at A/AA/AAA levels; PDFs are in scope wherever the underlying law says web content includes them.
PDF/UA — ISO 14289-1	Anyone producing or remediating a PDF that needs to conform	The technical requirements a tagged PDF must meet to be considered accessible: structure tree, reading order, alt text, and correct use of the PDF tagging features.
Section 508 (US federal)	US federal agencies and their contractors	Electronic and information technology, including documents, must meet the WCAG 2.0 AA-based standards set by the US Access Board.
ADA Title II web/mobile rule (US)	US state and local government entities	Web content and mobile apps — including PDFs — must conform to WCAG 2.1 AA. Original deadlines of April 2026/2027 were extended a year by the Department of Justice; entities with 50,000+ population now have until April 26, 2027, smaller and special-district entities until April 26, 2028.
Web Accessibility Directive (EU 2016/2102)	EU public-sector bodies	Websites and mobile apps of public-sector bodies, including downloadable documents such as PDFs published after September 2018, must be accessible; enforcement has applied since 2020.

None of these rules were written with redaction specifically in mind, but a redacted document released under a public-records law, a DSAR/SAR response, or a court filing doesn't stop being "web content" or a "downloadable document" just because part of it has been blacked out. If the releasing body is covered by one of these rules, the redacted output is too.

A workflow that keeps both goals honest

Trying to satisfy both requirements with one export is how you end up with a document that's neither properly redacted nor genuinely accessible. A workflow that keeps them separate and honest looks like this:

Redact first, in a copy, using a tool that removes the underlying content and rasterizes the affected pages — the same Secure-mode process this site recommends everywhere else. Treat this export as the authoritative, secure version of the document.
Ask whether anyone reading this specific release plausibly needs assistive technology, and whether the releasing body is under an accessibility obligation. If neither applies, the rasterized export is very often the end of the process.
If accessibility is required, don't try to retag the rasterized file — there's no structure left to retag. Instead, rebuild an accessible equivalent from the pre-redaction source: reproduce the surviving (non-redacted) content as a properly tagged PDF, or as accessible HTML or plain text, with headings, reading order and alt text added deliberately.
Never generate the accessible version by re-inserting the redacted content and relying on someone to remember to remove it later. Build it from a copy that already has the sensitive content deleted, not covered.
Run a PDF/UA or WCAG checker (a standalone checker, or the accessibility check built into a full-featured PDF editor) against the accessible version specifically — not the rasterized one, which will correctly fail every check because it has no tags at all.
Publish or send both, or make clear which one a given recipient is getting and why, rather than presenting the rasterized file as if it satisfies both requirements.

You can run the redaction half of this — mark what needs to disappear and export a rasterized, Secure-mode PDF with metadata stripped — with SladdPDF, entirely in your browser with no upload. It's built for that step specifically; it does not attempt to produce a tagged, screen-reader-navigable export, because no tool can honestly do both to the same file. See the NIST-aligned redaction checklist for the content side of the job this doesn't replace.

When rasterizing alone is fine, and when it isn't

Situation	What's usually right
Personal document shared one-to-one (a redacted bank statement, resume, or ID for a specific recipient)	A rasterized Secure-mode export is normally sufficient on its own; there's no general accessibility obligation on a private individual's one-off share.
Internal business document with named recipients	Same as above, unless your organization has its own accessibility policy or a recipient has requested an accessible format — in which case, treat that request the same as a legal one.
Public-records or FOIA/offentleglova response from a government body	Rasterize for security, but check whether the releasing body is covered by Section 508, ADA Title II, or an EU/national equivalent — if so, an accessible version is a separate deliverable, not optional polish.
Court filing or a document destined for a public docket	Follow the court's own formatting and accessibility rules in addition to the redaction rule (such as Federal Rule 5.2) — the two obligations run in parallel, not instead of each other.
Anything a specific reader has told you they need in an accessible format	Treat that as authoritative regardless of which category above the document falls into.

Running OCR on a rasterized, redacted page and calling the result "accessible" is the failure mode to watch for. It produces a text layer a screen reader can technically read, which can look like a fix — but without tags, reading order or alt text, it usually reads worse than nothing, because it's confidently wrong about the document's structure rather than obviously silent.

Redact first, in a browser that never uploads your file

SladdPDF handles the redaction half — draw over what needs to disappear, export in Secure mode so the text layer is gone for good, and strip metadata in the same pass. Free with no page limit; entirely local.

Redact a PDF now

Frequently asked questions

Does redacting a PDF make it inaccessible to screen readers?

Properly redacting a PDF for security — using rasterization so the underlying text can't be recovered — does destroy the tagged structure and text layer a screen reader relies on for that page. A redaction technique that preserved the tags would also likely preserve extractable text somewhere in the file, which defeats the point of redacting it. The two goals require different exports of the same content.

Can a PDF be both securely redacted and PDF/UA accessible?

Not as a single rasterized export. A rasterized page has no text layer or structure tree left to tag, and a fully tagged, PDF/UA-conformant page has a text layer that a determined reader could attempt to extract from around the edges of a redaction. Organizations that need both typically produce two versions: a rasterized secure export, and a separately built, tagged accessible version of the non-redacted content.

Do I have to make every redacted document accessible?

No. There's no general obligation on a private individual or business sharing a one-off document. The obligation attaches to specific releasing bodies and content types — US federal agencies under Section 508, US state and local governments under the ADA Title II rule, and EU public-sector bodies under the Web Accessibility Directive, among others — and to any recipient who has specifically requested an accessible format.

What is PDF/UA and how is it different from WCAG?

WCAG (the Web Content Accessibility Guidelines) is a general, technology-neutral standard for accessible content, covering web pages and applications broadly. PDF/UA (ISO 14289) is PDF-specific: it defines exactly which tagged-PDF features a file must use, and how, to be considered accessible, and it's written to complement WCAG rather than replace it — a PDF can be evaluated against both.

What are the current ADA Title II deadlines for government PDFs?

The Department of Justice's Title II rule originally set April 2026 and April 2027 deadlines by population size, then extended both by a year in 2026. State and local government entities serving 50,000 or more people now have until April 26, 2027 to bring web content and mobile apps — including PDFs — into WCAG 2.1 AA conformance; smaller and special-district entities have until April 26, 2028.

Sources