What Are HTML Overlays?
An HTML overlay is a technology approach where a vendor's system intercepts PDF links on a website and replaces them with HTML content. When a user clicks a PDF link, they don't download a PDF. Instead, they're served a webpage that displays the PDF content as HTML—typically a transcribed or extracted version of the PDF text. The vendor maintains JavaScript code on your website that detects PDF links and redirects them to their hosted service.
The original PDF remains unchanged on your server, and the vendor maintains a separate HTML wrapper that provides an accessible alternative. The pitch is attractive: "Your PDFs stay exactly as they are. We provide accessibility on top. No changes to your PDFs. No ongoing remediation. Just drop in our code."
But this architecture creates a fundamental problem: the PDF itself is still inaccessible. You haven't fixed anything. You've added a workaround that only works under specific conditions—when users access your website while JavaScript is enabled.
How Overlays Actually Work: The Technical Mechanics
JavaScript Interception
An overlay vendor embeds JavaScript code on your website. This code runs when the page loads and:
- Scans the DOM for PDF links (href ending in .pdf)
- Intercepts clicks on those links
- Redirects the click to the vendor's service (usually vendor.com/proxy?url=your-pdf.pdf)
- Loads an HTML version of the PDF in an iframe or new page
- Displays transcribed or extracted text with navigation controls
The user sees what appears to be the PDF content, but it's actually HTML served by a third party. This has several implications, which we'll explore below.
HTML Transcript Display
The vendor's system performs OCR (optical character recognition) or PDF text extraction to capture the content, then serves it as HTML. This HTML version might include:
- Extracted or transcribed text
- Simple heading structure
- Basic search functionality
- Navigation controls (next page, previous page)
- An attempt at recreating the visual layout
Importantly, the vendor cannot know the semantic structure of the original PDF. If the PDF is a scanned document (image of text), the OCR quality might be poor. If the PDF is a form, the form fields are essentially invisible to the overlay—users can't fill them out. If the PDF has complex tables, sidebars, or non-linear layout, the overlay's transcription is often incorrect or confusing.
The User Never Touches the Original PDF on Your Server
When accessed through the overlay, the user's screen reader or magnification software interacts with the HTML transcript, not the PDF. The original PDF file on your server remains untouched and unrepaired. This is crucial: it means the overlay provides what seems like accessibility, but only when using it through the specific vendor's interface on your website.
Why the Difference Matters: Legal Compliance
Under WCAG 2.1 AA and the ADA Title II and Title III rules, "alternative formats" are not a complete solution. The ADA Accessibility Guidelines (ADAAG) explicitly state that alternative formats supplement, but don't replace, the need for the primary resource to be accessible.
When someone tries to download your PDF for offline use, email it to a colleague, store it in a shared drive, or open it in their native PDF reader or screen reader, the overlay vanishes. They're left with an inaccessible document. The two-tier experience creates legal exposure because:
Overlays Create Unequal Access
A disabled user who uses screen reader software or prefers native PDF readers gets a different experience than a non-disabled user who simply downloads the PDF or opens it in Adobe Reader. The DOJ has been explicit about this in guidance documents: overlays that provide conditional access based on disability are not compliant solutions. They're workarounds that create discrimination through differentiation.
The legal principle is simple: disabled users should have equal access to content, not a separate access path. An overlay that requires using a vendor's interface is by definition separate access. A non-disabled user can download the PDF, email it, and open it anywhere. A disabled user cannot—they're locked into the overlay interface.
Email and Offline Scenarios Fail Completely
If your PDF is emailed to someone (either internally or externally), attached in a shared drive, forwarded via collaboration tools like Slack or Teams, or downloaded to someone's device, the overlay doesn't follow it. The user with a screen reader or magnification tool opens an inaccessible PDF on their desktop. This is exactly the scenario the DOJ and courts have targeted in enforcement actions.
Courts have found that organizations cannot claim compliance when content becomes inaccessible once it leaves the controlled website environment. Real-world accessibility requires documents to work across all distribution channels—downloaded, emailed, printed, shared.
Overlays Don't Meet PDF/UA Standard
PDF/UA (Universal Accessibility) is the ISO standard for accessible PDFs. A PDF that passes PDF/UA validation is genuinely accessible—it works with screen readers, magnification software, all native PDF readers, and all devices. An overlaid PDF that hasn't been remediated fails PDF/UA validation every single time. Courts and DOJ investigators increasingly use PDF/UA compliance as a technical benchmark for determining accessibility.
When an auditor or plaintiff's attorney tests your PDF (by downloading it from your server and running it through PAC, Adobe's Accessibility Checker, or NVDA), the overlay plays no role. The PDF is tested in isolation. If the PDF is not PDF/UA-compliant, the test fails. The overlay—which only exists on your website—provides no defense.
The Technical Reality: What Overlays Don't Do
No Internal Tag Structure
Overlays don't modify the PDF's internal structure. A tagged PDF has a hierarchical "tag tree"—an internal roadmap that defines which elements are headings, paragraphs, lists, tables, etc. This tag tree is what screen readers and assistive technology use to understand document semantics.
An overlaid PDF still lacks this structure. When someone opens it in a PDF reader and activates screen reader mode, the reader has no semantic structure to navigate. The content is read in visual rendering order, which often makes no sense. A multi-column layout might jump chaotically between columns. A sidebar might be read in the middle of main content. Lists might not be recognized as lists.
No Alt Text in the PDF
Images in overlaid PDFs are not given alt text. The overlay might describe images on the HTML version, but that description is not embedded in the PDF itself. Download the PDF and open it in Acrobat Reader with screen reader support? The images are skipped entirely—the screen reader has no alt text to read.
The HTML transcript might say "Image: Sales chart showing 2025 revenue by region." But when someone opens the original PDF in a screen reader, the image is simply passed over. There's no accessible description in the PDF itself.
No Reading Order Repair
Multi-column layouts, sidebars, headers, and complex visual designs often have reading orders that don't match logical flow. A truly remediated PDF has the reading order corrected in its tag tree—the remediation tool physically reorders the tagged content so it flows logically.
An overlaid PDF still has the broken reading order. Open it in a screen reader and it jumps chaotically. A page with "Main content on the left, sidebar on the right" might be read "sidebar, main content, footer, header" because that's how the PDF's visual rendering order arranges them. The overlay doesn't fix this because it doesn't touch the PDF.
No Language Metadata
Accessible PDFs declare their language in metadata (e.g., "this document is in English"). Screen readers use this metadata to pronounce words correctly and apply proper text-to-speech rules. An English document read with French pronunciation rules is incomprehensible.
Overlaid PDFs don't have this metadata. A blind user's screen reader can't determine language and mispronounces content. Multilingual documents (even PDFs with a single phrase in another language) lack the language tagging that makes them readable.
No Form Field Accessibility
If your PDF is a form—an application, survey, or fillable document—the overlay provides almost zero help. Form fields in overlaid PDFs remain inaccessible. A screen reader user can't tab through fields, can't understand field labels, and can't fill out the form effectively.
Some vendors claim their overlay supports forms. But in reality, they're usually just displaying the form as static text. A user looking for a solution to fill out your form using a screen reader would have to manually transcribe data from the HTML transcript into another tool—not acceptable for actual accessibility.
Specific WCAG 2.1 AA Criteria That Overlays Fail
WCAG 1.1.1 - Non-text Content
This criterion requires that images have text alternatives. Scanned PDFs are essentially images of text. An overlay can extract and transcribe that text, but the transcription lives in HTML, not in the PDF. The PDF itself still has images with no alt text. A screen reader user who downloads the PDF finds images with no description.
WCAG 1.3.1 - Info and Relationships
Information and structure must be programmatically determinable. An overlay provides structure in HTML, but the PDF has no structure. The relationships between headings, content, and lists exist in the overlay, not in the PDF. A user accessing the PDF directly has no way to programmatically determine these relationships.
WCAG 2.1.1 - Keyboard
All functionality must be accessible via keyboard. If your overlay doesn't handle PDF form navigation perfectly, users who can't use a mouse are stuck. Many overlays don't fully support keyboard navigation. Additionally, the original PDF's form fields may not be keyboard-accessible at all—the overlay doesn't fix this.
WCAG 3.1.1 - Language of Page
The language must be identified in the document. Overlaid PDFs don't have language metadata. The PDF is non-compliant with this criterion.
WCAG 4.1.2 - Name, Role, Value
Form fields, buttons, and interactive elements must have accessible names and roles. This requires semantic structure in the PDF. Overlays don't modify the PDF's internal structure, so this criterion is not met in the actual PDF. Form fields in the PDF may lack proper labels, be unlabeled, or be inaccessible to assistive technology.
WCAG 1.4.3 - Contrast
Text must have sufficient color contrast. An overlay might rerender text with better contrast in HTML, but the original PDF's contrast issues remain. If the original PDF has low-contrast text, a screen reader user who accesses the PDF directly experiences the contrast problem (assuming they use low vision or have color deficiency).
Legal Precedent: Overlays Are Rejected by Courts and Regulators
The Hassayampa Case
In Hassayampa Steering Committee v. Arizona Department of Water Resources, plaintiffs sued because state government PDFs were inaccessible. The state's defense was to provide an accessible alternative—HTML transcripts on the website. The court rejected this defense, finding that providing an accessible alternative does not remedy an inaccessible primary resource. The court noted that alternative formats are supplements, not solutions. The agency was required to remediate the PDFs themselves, not just provide HTML alternatives.
This case is frequently cited as the legal precedent for why overlays are insufficient. The principle is clear: you can't claim compliance by leaving the primary resource inaccessible and adding a workaround.
DOJ Settlement Agreements
In multiple DOJ settlements with government agencies (including several school districts, universities, and municipalities), the requirement has been explicit: remediate PDFs to PDF/UA compliance, not just provide HTML overlays. The DOJ position is that overlays are a supplement at best, not a primary remediation approach.
Recent settlements have included language explicitly forbidding reliance on overlays as a compliance solution. Organizations are required to produce genuinely accessible PDFs, with overlays being an optional additional service, not the primary accessibility solution.
GSA Section 508 Office Guidance
The Section 508 Office of the General Services Administration (GSA) has clarified that overlays do not meet Section 508 requirements. Federal agencies—which are under the strictest accessibility mandates—are explicitly advised not to rely on overlays for primary compliance. The GSA's official guidance states that PDFs must be remediated, and alternative formats can supplement but not replace remediation.
Plaintiffs' Bar Positioning
Accessibility litigation attorneys actively market their services against organizations using overlays. The plaintiff's bar views overlays as insufficient remediation and low-hanging fruit for settlements. An organization can expect that if they're sued for inaccessible PDFs and are relying on overlays, the plaintiff's attorney will easily demonstrate that the overlay is inadequate—download a PDF, show it fails accessibility testing, and the case is effectively over.
What Happens When Your PDF Is Tested
When compliance auditors (or plaintiffs' attorneys) test your PDFs, they follow a specific process designed to expose overlay dependence:
Step 1: Download and Open the PDF Directly
They download the actual PDF file from your website or server. They don't access it through your website interface. The overlay doesn't follow. They have the raw file.
Step 2: Run Adobe Acrobat's Accessibility Checker
They open the PDF in Adobe Acrobat (or Preview on Mac) and run the built-in Accessibility Checker tool. This tool validates against PDF/UA and WCAG standards. An overlaid PDF that hasn't been remediated will fail this check—often with dozens of errors: missing alt text, no tag structure, incorrect reading order, missing language metadata, malformed form fields.
Step 3: Test with Screen Reader
They open the PDF in Adobe Reader or another PDF viewer with NVDA (JAWS, NVDA, or VoiceOver on Mac). They listen to how the content is read. If the PDF has no tag structure, the screen reader reads it in visual rendering order—often nonsensically. They document: "Screen reader reads sidebar before main content," "Form fields are announced without labels," "Images have no alt text."
Step 4: Check PAC Validation
They run the PDF through PAC (PDF Accessibility Checker), a free tool from the PDF Association that validates PDF/UA conformance. PAC generates a detailed report of all violations. An overlaid PDF typically generates dozens of failures.
Step 5: Document and Report Failures
They document the accessibility failures in the PDF itself. They create a report: "PDF fails WCAG 2.1 AA criteria 1.1.1, 1.3.1, 3.1.1, 4.1.2" with evidence screenshots. If that PDF is used as evidence in litigation, the failures are clear and measurable. The overlay provides no defense because the overlay was never tested—only the actual PDF file.
Download Scenario Failure: The Real-World Problem
Consider a typical user journey:
- A person using a screen reader visits your website
- They find a PDF link to a document they need
- The overlay loads, and they can read the transcript
- They want to save the document for offline reading
- They download the PDF from your server
- They open it on their device with their screen reader
- The document is completely unreadable—no tag structure, no alt text, no reading order
This scenario is exactly what plaintiffs' attorneys use in litigation. They argue: "The organization provided temporary access through an overlay but made the actual document completely inaccessible. When the disabled user tried to exercise independence by downloading the document, they hit a wall. This is discrimination."
The Business Case Against Overlays
False Economy and Hidden Long-Term Costs
Overlays are often cheaper than genuine PDF remediation upfront. You might pay $500–$2,000/month for an overlay service. But when you consider legal risk, overlays are vastly more expensive. A single accessibility lawsuit can cost $100,000–$500,000+ in legal fees and settlements. An overlay that fails audit scrutiny is exactly the kind of "half-measure" that plaintiffs' attorneys love—it shows effort that's technically insufficient, which suggests negligence rather than good-faith compliance.
Additionally, overlay costs are ongoing. You're paying monthly indefinitely. Genuine remediation is often a one-time cost (or a predictable annual cost for new documents), after which your PDFs are compliant forever.
Operational Friction and Vendor Lock-in
Overlays require ongoing maintenance. Every time you post a new PDF, you must ensure the overlay captures it. If a PDF is emailed or shared outside your website, the overlay is useless. Your staff must manage two systems: the website (with overlay code) and the overlay infrastructure (vendor's dashboard). If the vendor goes out of business or raises prices dramatically, you're stuck.
Additionally, overlay JavaScript adds complexity to your website. It can conflict with your own JavaScript, affect page performance, cause issues with certain browsers or assistive technologies, and create debugging headaches.
User Experience Degradation
Overlay interfaces are often clunky. Users navigate through a specialized web interface instead of using native PDF tools they're familiar with. For many disabled users, this is worse than just providing accessible PDFs. A user with a preferred screen reader or magnification setup has to use the overlay's interface instead. A user who wants to annotate a PDF can't do so through the overlay. A user who wants to search the PDF has to use the overlay's search instead of PDF reader search.
Liability Exposure
By using an overlay, you're creating evidence that you knew PDFs should be accessible but chose a workaround instead. In litigation, this looks worse than "we didn't know" or "we're actively fixing it." It looks like "we knew but did the minimum." Courts view this unfavorably when determining liability and damages.
What Genuine PDF Remediation Actually Does
The PDF Becomes Compliant
A remediated PDF passes PDF/UA validation. It has:
- A proper tag tree with correct semantic hierarchy (headings, paragraphs, lists, tables, figures)
- Alt text for all images embedded in the tag tree
- Correct reading order reflecting logical flow, not visual order
- Language declarations (document level and span level for multilingual content)
- XMP metadata documenting accessibility features, title, author, subject
- Properly tagged and labeled form fields
- Artifact marking for decorative elements (page numbers, headers, footers, backgrounds)
- Sufficient color contrast
- No reliance on color alone to convey information
Works Everywhere
Download the PDF, email it, open it in any PDF reader, use it on any device—it works everywhere. A screen reader user has the same experience whether they access it through your website, receive it by email, download it to their device, or store it in a shared drive. The accessibility is intrinsic to the PDF, not dependent on a website interface.
Passes Technical Validation
Run the PDF through Adobe Acrobat's Accessibility Checker: passes. Run it through PAC 2024: passes. Open it in NVDA, JAWS, or VoiceOver: reads logically and completely. The PDF is objectively accessible.
Defensible in Litigation
If your remediated PDF is audited by a plaintiff's attorney or DOJ investigator, it passes their technical tests. You have documentation (remediation reports, validation results, audit logs) showing compliance effort. This is very different from a half-measure overlay that fails on first inspection.
Automated Remediation vs. Overlays: The Right Comparison
Modern automated remediation tools (like RemeDocs) actually remediate PDFs—they modify the PDF files themselves to add tags, alt text, reading order fixes, and metadata. The output is a PDF/UA-compliant file that passes technical validation.
This is fundamentally different from an overlay. An overlay wraps a broken PDF and hopes users never access the original. Automated remediation fixes the PDF itself.
For large repositories, automated remediation at scale is both more cost-effective and legally compliant than overlays:
- Cost per page: ~$0.10–$0.50 for automated remediation (vs. $500–$2,000/month for overlay indefinitely)
- Time for 1,000-page batch: 2–5 days for automated remediation (vs. ongoing overlay maintenance)
- Compliance level: Genuine PDF/UA conformance (vs. overlay workarounds)
- Long-term cost: One-time remediation + new-document creation compliance (vs. perpetual overlay subscription)
How to Evaluate Whether a Vendor Is Doing Real Remediation or Just Overlay Tricks
The Right Questions to Ask
When evaluating a vendor or approach, ask:
- "Do you modify the PDF file itself?" If they say "no, we provide an accessible interface on top," that's an overlay. Real remediation modifies the PDF.
- "Can the remediated PDF pass PDF/UA validation?" If they say "maybe" or "we don't validate against PDF/UA," that's a red flag. Remediated PDFs should pass PAC validation.
- "What happens if I download the remediated PDF and open it in my PDF reader?" If they hedge or say "it depends," they're probably selling overlays, not remediation.
- "Will you provide PAC validation reports?" Real remediation tools can. If they won't, they don't have a real remediation process.
- "Does the solution work offline and across all PDF readers?" Real remediation does. Overlays don't.
Red Flags for Overlay-Only Vendors
- Marketing focuses on "alternative access" rather than "fixing PDFs"
- Mentions "transcripts" or "HTML versions" prominently
- Requires JavaScript embedding in your website
- Has monthly recurring costs with no work being done on your PDFs
- Can't provide PAC validation reports or PDF/UA certification
- Claims overlays are "just as good as" real remediation
- Avoids discussing what happens when PDFs are downloaded or shared outside the website
Green Flags for Real Remediation
- Delivers modified PDF files that you own and control
- Provides PAC validation reports or PDF/UA-1 certification
- Discusses tag tree structure, alt text implementation, and reading order
- Explains the PDF/UA standard and how their process ensures compliance
- Offers transparent pricing (often per-page or per-batch, not monthly subscriptions)
- Provides before/after accessibility comparisons
- Can explain what specific WCAG and PDF/UA criteria are met
The Legal and Practical Recommendation
HTML overlays are well-intentioned but legally insufficient. They create a false sense of accessibility compliance while leaving the actual PDFs broken. When tested independently, they fail. When accessed outside the website, they disappear. When litigation arrives, they provide no defense.
Genuine PDF remediation—fixing the PDFs themselves to PDF/UA compliance—is the only legally defensible approach. The PDF becomes compliant, works everywhere, passes technical validation, and holds up in audits and litigation.
If you're currently relying on overlays, now is the time to move to genuine PDF remediation. Your legal exposure depends on it. The long-term cost is lower, the compliance is real, and your users—particularly those with disabilities—get actual accessibility instead of a workaround.
Ready to make your PDFs accessible?
Upload any PDF and get a fully compliant, audit-ready document back in seconds.
Try free PDF audit