Guided remediation vs. automated remediation: Choosing the right approach for PDF accessibility

Choosing between automated and guided PDF remediation is a risk decision: Your document type and regulatory exposure determine the right method, and organizations that skip that analysis end up with accessible PDFs on paper but functionally broken documents for screen reader users.

Speed is easy to optimize for. Compliance is harder. Most organizations treat PDF remediation as a backlog problem — how fast can we get through these files? — and default to automation across the board because it's cheaper and faster. Choosing the wrong PDF remediation approaches costs more in the long run. That works fine until a complex table, scanned form, or multi-column layout comes out structurally wrong: tagged on paper, useless in practice, and still a liability under ADA Title II, Section 508 or the EAA.

Siteimprove's analysis of remediation programs points to document type and regulatory exposure, not volume, as the deciding factors. This guide maps when automation is the right call, when human review is required, and how platform governance makes both approaches sustainable at scale. You'll learn to:

• Identify which PDF accessibility standards govern your document library and what each requires.
• Build a document-type framework that routes files to the right remediation workflow.
• Assess the legal exposure created when automation handles documents it can't reliably fix.
• Govern both approaches at scale without rebuilding your program after every compliance deadline.

Let's start with what PDF remediation does and where the automated/guided distinction begins to matter.

What PDF remediation does (and where it gets complicated)

PDF remediation modifies a document's underlying tag structure so assistive technologies, screen readers in particular, can interpret it correctly: Reading order, element identification, alt text, table relationships, and form field labels all depend on tags being present and accurate.

Siteimprove's work with document-heavy organizations regularly turns up "remediated" PDFs that passed automated checks but were completely unusable with a screen reader. The tag tree looked fine on the surface. Dig deeper, and the reading order was scrambled, table headers were unassociated, and scanned pages had no text layer at all. Compliant by one metric; inaccessible in practice.

The gap between passing automated checks and working for screen reader users is the core problem with treating remediation as a volume exercise.

The automated vs. guided distinction defined

Automated remediation, including PDF auto-tagging, uses software to detect and apply accessibility fixes without human intervention. This method is fast, scalable, and reliable when used for simple, consistently formatted documents.

Guided remediation, sometimes called manual or human-in-the-loop remediation, puts a human reviewer in the loop. The remediator makes structural judgments that software can't: interpreting ambiguous reading order, manually tagging complex merged-cell tables, and verifying that alternative text is descriptive.

Budget shouldn't decide the choice between them. A PDF that doesn't conform, or that a screen reader user can't actually navigate, is a problem regardless of what tool touched it, and under ADA Title II document remediation requirements, the liability sits with the organization, not the vendor.

How to understand PDF accessibility standards

Most remediation programs get scoped around one standard. Two standards shape PDF accessibility, and both can apply to the same document library.

Siteimprove has seen teams get halfway through a remediation project before legal flagged a PDF/UA requirement in a contract nobody had accounted for. Going back through hundreds of documents for a second pass is expensive and entirely avoidable.

WCAG sets outcome-based criteria every document must meet; PDF/UA adds PDF-specific structural requirements. Here's where they diverge:

Automated tools can check some WCAG success criteria, but many require human judgment, and the same is true of PDF/UA. Whether a table header maps to the right cells or whether reading order reflects what the author intended are not calls software can make reliably. A human reviewer can.

So, before you touch a single file, confirm which framework your organization falls under. Federal agencies reference Section 508 technical standards for ICT, which incorporate WCAG 2.0 AA. State and local governments sit under Title II. The answer shapes your tool requirements, your staffing model, and which documents need guided review versus automated processing.

Legal requirements for accessible digital documents

The legal frameworks governing PDF accessibility don't evaluate your remediation method; rather, they evaluate whether the document works. A PDF that doesn't conform to the applicable standard is non-compliant regardless of whether a human or an algorithm processed it.

One of the most common assumptions Siteimprove hears from document teams is that running files through an automated tool covers their liability. It doesn't. Under ADA Title II, Section 508 requirements for federal documents, and the EAA, compliance turns on the result, not the method. What matters is whether the document conforms and whether a user with a disability can actually use it, not which tool produced it.

Here are the three frameworks you're most likely to deal with:

• ADA Title II: Applies to state and local governments. The DOJ's 2024 rule requires web content and mobile apps, including PDFs and other documents posted on them, to conform to WCAG 2.1 AA. Archived content and preexisting documents are excepted unless they're still used to access a service, program, or activity. Enforcement runs through DOJ investigations and settlement agreements, as well as private lawsuits, and the underlying Title II obligation applies now, not only from the compliance date.
• Section 508: Applies to federal agencies, and reaches vendors through procurement and contract terms. The Revised 508 Standards require public-facing electronic content, plus internal content in nine categories of official agency communication, to conform to WCAG 2.0 Level A and AA. That includes PDFs contractors deliver to an agency.
• EAA: Applies to businesses providing specific products and services in the EU market, including e-commerce, consumer banking, e-books, and electronic communications, and to the documents those services provide. Micro-enterprises providing services are exempt. Its obligations have applied since 28 June 2025, and each member state enforces it through its own national law. EN 301 549 V3.2.1, which incorporates WCAG 2.1 AA, remains the cited standard for demonstrating conformance until V4.1.1, published in September 2026 with WCAG 2.2, is cited in the Official Journal.

None of the frameworks above will accept "we used an automated tool" as a defense. If the document doesn't work for a screen reader user, the organization is exposed. Complex PDFs, such as scanned files, multi-column layouts, and fillable forms, are where automated remediation most often produces that outcome. They look processed. They aren't usable. And the liability doesn't disappear because software touched them first.

Best practices for tagging PDFs for screen readers

The core PDF tagging best practice is accuracy, not presence: every element needs the right tag, in the right order. That's where the automated versus guided decision gets important quickly.

Tags tell a screen reader what every element in a document is: a heading, a paragraph, a table header, an image with a description. Without them, a screen reader encounters a flat stream of characters with no structure. With incorrect tags, it encounters structure that actively misleads. A user navigating by heading lands in the wrong place. A table reads out of order. An image gets skipped entirely.

It's not unusuak to find a PDF that passed automated accessibility checkers and was completely unusable with NVDA. The tag tree existed. The reading order was wrong, merged table cells were untagged, and a three-column layout was being read left-to-right across all three columns simultaneously. A tagged PDF with a broken structure can be worse than an untagged one, because it misleads rather than simply failing.

Prioritizing which PDFs to remediate first starts with knowing which document types are in your library. That inventory directly determines how much of your workflow can be automated and how much needs human eyes.

Tools and software for PDF remediation: A decision framework

The right remediation tool matches the document type and compliance context. Organizations need a documented decision framework, not a single-vendor selection, to govern which documents go through automated workflows and which require guided review.

The same pattern shows up at the tool level. Siteimprove regularly sees teams buy the most powerful remediation platform available and still end up with non-compliant documents. The tool wasn't the problem. Routing every document through the same workflow was.

Here's where automated tagging holds up and where it doesn't:

For straightforward linear documents, such as a one-column report or a standard letter, automated tagging produces solid results. The document structure is predictable enough that software handles it well.

But complexity breaks that reliability quickly. Scanned files need OCR before any tagging can happen, and the quality of what comes out depends heavily on scan resolution and layout. Multi-column formats get read in the wrong order, merged table cells lose their header associations, and fillable form fields end up labeled incorrectly, which means a screen reader user filling out that form gets the wrong instructions for every field.

Choose automated remediation when:

• Documents are simple, linear, and consistently formatted
• Volume is high, and document types are predictable
• Compliance deadline pressure makes throughput the priority

Choose guided remediation when:

• Documents contain complex tables, merged cells, or multi-column layouts
• Files are scanned or have low-quality source formatting
• Regulatory exposure is high (federal contracting, Title II compliance, higher education)

Most libraries end up with a hybrid workflow: document complexity and regulatory exposure decide the lane for each file, not volume or budget.

Routing decisions need to be documented, repeatable, and auditable, especially when a regulator comes asking. Organizations without in-house expertise often turn to a PDF remediation service to handle complex document types.

Case studies of successful PDF remediation projects

In Siteimprove's experience, the organizations that get PDF accessibility right share one habit: They triage first. Document type and risk level determine the workflow; automation doesn't get applied uniformly across the library.

The City and County of Denver faced having a web team of two managing 6,000 pages across multiple sites, with no audit tool capable of crawling their 12,000 PDFs. Using Siteimprove.ai to surface and prioritize issues, content publishers across 40-plus departments received automated reports flagging PDF errors and could address them directly. Quality assurance scores rose across the organization's multiple sites.

Higher education presents a different challenge. Faculty, staff, and department admins all publish PDFs, often with no accessibility training. Leading institutions are now asking their teams to "think before you PDF" to determine whether a document needs to be a PDF at all before any remediation begins. That question alone reduces the backlog before a single file gets touched.

The pattern across both contexts is the same: Governance (knowing what's in the library, classifying by complexity, and routing to the right workflow) is what separates a one-time remediation push from a program that holds up 12 months later.

Digital document accessibility tools and platform governance

Siteimprove's view is that once a document library runs into the hundreds or thousands of files, neither automated nor guided remediation scales without ongoing accessibility governance sitting above both.

That layer does four things: inventories the library, classifies documents by complexity and risk, routes them to the right workflow, and tracks digital accessibility compliance status over time. Without it, teams end up manually spot-checking, which works until it doesn't, usually right before an audit.

Siteimprove.ai surfaces and categorizes PDF accessibility issues across an entire document library, replacing that spot-checking with systematic, prioritized insight. Compliance status is visible at the library level, not just the individual file level. That's the difference between knowing a document was processed and knowing whether it actually meets the standard.

A few trends worth tracking as this space matures:

• AI-assisted classification: Automatically sorting documents by complexity and routing them to the appropriate workflow before human reviewers touch them
• Automated severity scoring: Flagging which documents carry the highest compliance risk so teams can prioritize accordingly
• Real-time compliance dashboards: Giving leadership visibility into remediation progress without waiting for quarterly reports

The goal isn't faster remediation or more thorough remediation. It's a governed workflow where both approaches run in the right lanes; document remediation at scale becomes an operational standard rather than a project that restarts after every compliance deadline.

Choose the right approach: A framework, not a formula

Both automated and guided remediation have legitimate roles. The decision framework is what matters: matching method to document type, governing both workflows with platform-level oversight, and measuring outcomes against the standards that apply.

To scope a remediation program that holds up:

• Inventory your library by document type and complexity.
• Classify by regulatory exposure and remediation risk.
• Route simple documents to automated workflows; complex ones to guided review.
• Monitor compliance status continuously so you're not rebuilding after every deadline.

PDF accessibility isn't a backlog to clear. Organizations that treat ongoing accessibility governance as an operational discipline, rather than a project with an end date, are the ones that don't find themselves starting over 12 months later.