Does Failing a PDF Checker Mean Failing Compliance & Accessibility?

Understanding the Limits of Automated PDF Accessibility Testing Under WCAG 2.1, Section 508, and the ADA

Despite the growing availability of automated accessibility checkers, many organizations misunderstand what true ADA and Section 508 compliance really means. Automated tools like Adobe Acrobat, axes4, or PowerPDF often flag “failures” that don’t actually prevent a document from being accessible to users with disabilities. This is especially true with complex or legacy PDF documents.

This raises questions such as: “If my document failed a compliance checker, am I in violation?” or “What if I can’t correct that document-level issue, but I know my document is accessible?”

The U.S. Department of Justice (DOJ) makes it clear that public entities must ensure conformance to Web Content Accessibility Guidelines (WCAG) 2.1 Level AA to the extent the criteria can be applied—recognizing that not every technical rule applies cleanly to every document type. In short, a failed checker doesn’t automatically mean noncompliance.

Throughout this article, you’ll find direct citations from the Department of Justice, ADA Title II, and the World Wide Web Consortium (W3C) that clarify what the DOJ’s final rule means for digital document accessibility and compliance.

Helpful Initial Links

• Code of Federal Regulations: PART 35—NONDISCRIMINATION ON THE BASIS OF DISABILITY IN STATE AND LOCAL GOVERNMENT SERVICES
• W3C Group Note: Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies (WCAG2ICT)
• ADA – Fact Sheet: Fact Sheet: New Rule on the Accessibility of Web Content and Mobile Apps Provided by State and Local Governments

The Problem: Automated Checkers & Interpretation

 Automated compliance checkers are powerful tools for assessing the overall accessibility of a document, identifying issues that can be corrected, verifying logical reading order, and flagging accessibility potential barriers. However, these tools can only evaluate what’s directly in front of them. 

Checkers like Adobe Acrobat, axes4, and PowerPDF can’t interpret a document’s intent, usability, or real-world experience for someone using assistive technology. A checker may identify a page of content as an image when in fact it contains text that’s properly tagged; however, the checker doesn’t know the difference.

For example, a checker might flag a contrast ratio failure because of how a file was created or scanned, even though the content is fully readable and accessible through optical character recognition (OCR) and properly represented in the document’s tag tree. Conversely, a document might technically pass WCAG tests but still present a poor experience for screen reader users because of confusing structure or mislabeled elements.

The core goal of the ADA, especially under Title II, is to ensure the digital content is accessible to everyone. Passing an automated checker is helpful, but it’s not the same thing as being truly accessible or compliant. 

Where Does It Say This in the Final Ruling?

Before getting into the citations, it’s important to clarify that these points specifically address conventional electronic documents under ADA Title II’s Final Ruling. The key section to review is Subpart H — Web and Mobile Accessibility (§ 35.200 – § 35.205).

Defining “Web Content”

28 C.F.R. § 35.104 — Definitions: Web Content

“Web content means the information and sensory experience to be communicated to the user by means of a user agent, including code or markup that defines the content's structure, presentation, and interactions. Examples of web content include text, images, sounds, videos, controls, animations, and conventional electronic documents.”

“Conventional electronic documents means web content or content in mobile apps that is in the following electronic file formats: portable document formats (“PDF”), word processor file formats, presentation file formats, and spreadsheet file formats.”
Source: 28 CFR § 35.104

In Paragraph 304 of the Federal Register discussion of Part 35, commenters requested a narrower definition of “web content.” However, the DOJ stood by its broader definition, explaining that “…the framework in this part appropriately balances the considerations implicated by this definition.” 

Determining the Compliance Basis – Where Does it Mention WCAG 2.1 AA?

“A public entity… shall ensure that the web content and mobile apps that the public entity provides or makes available, directly or through contractual, licensing, or other arrangements, comply with Level A and Level AA success criteria and conformance requirements specified in WCAG 2.1, unless the public entity can demonstrate that compliance with this section would result in a fundamental alteration in the nature of a service, program, or activity or in undue financial and administrative burdens.”
Source: 28 CFR § 35.200(b)

Additional Clarifying Sections in ADA Title II (Part 35 – Subpart H)

“In those circumstances where personnel of the public entity believe that the proposed action would fundamentally alter the service, program, or activity or would result in undue financial and administrative burdens, a public entity has the burden of proving that compliance with § 35.200 would result in such alteration or burdens.”

“If an action would result in such an alteration or such burdens, a public entity shall take any other action that would not result in such an alteration or such burdens but would nevertheless ensure that individuals with disabilities receive the benefits or services provided by the public entity to the maximum extent possible.”

Source: 28 CFR § 35.204

§ 35.205 — Effect of Noncompliance That Has a Minimal Impact on Access

“A public entity that is not in full compliance with the requirements of § 35.200(b) will be deemed to have met the requirements of § 35.200 in the limited circumstance in which the public entity can demonstrate that the noncompliance has such a minimal impact on access that it would not affect the ability of individuals with disabilities to use the public entity's web content or mobile app… with substantially equivalent timeliness, privacy, independence, and ease of use.”

Source: 28 CFR § 35.205

WCAG 2.1 AA & Conventional Electronic Documents – Does a “Pass” Mean Compliant?

There is no law, DOJ rule, or court case stating that a PDF—or any website—must pass a third-party accessibility checker to be deemed compliant. While these tools are useful, they are not the compliance standard.

The DOJ defines compliance through WCAG 2.1 AA, but also recognizes in § 35.205 that:

“A public entity may be deemed compliant if any WCAG nonconformance has such a minimal impact that it does not affect the person’s ability to access the content with substantially equivalent timeliness, privacy, independence, and ease of use.”

Think of accessibility checkers like spell checkers: a spell checker might mark a sentence as “wrong,” but the sentence still makes sense. The same applies here—checkers can’t evaluate human context, meaning, or usability.

DOJ References to WCAG2ICT – WCAG 2.1 AA was Intended for Websites—What about PDFs?

The DOJ references that public entities should consult WCAG2ICT on how to apply success criteria to conventional electronic documents.

“In determining how to make conventional electronic documents conform to WCAG 2.1 Level AA, public entities may find it helpful to consult W3C's guidance on non-web information and communications technology, which explains how the WCAG success criteria can be applied to conventional electronic documents.”

Source 28 CFR § Paragraph 310

Paragraph 310 (Footnote 23)

“W3C explains in its guidance on non-web information and communications technology that ‘[w]hile WCAG 2.2 was designed to be technology-neutral, it assumes the presence of a ‘user agent' such as a browser, media player, or assistive technology as a means to access web content. Therefore, the application of WCAG 2.2 to documents and software in non-web contexts require[s] some interpretation in order to determine how the intent of each WCAG 2.2 success criterion could be met in these different contexts of use.’ W3C, Guidance on Applying WCAG 2.2 to Non-Web Information and Communications Technologies (WCAG2ICT): Group Draft Note (Aug. 15, 2023)”

Source 28 CFR § Paragraph 310 Footnote 23

While the DOJ directs organizations to refer to the W3C’s Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies (WCAG2ICT) for additional context when evaluating conventional electronic documents, they (DOJ) also notes that they understand not all success criteria are applicable to electronic documents but should be used where they apply.

Paragraph 402 (Footnote 72)

“The Department understands that some WCAG 2.1 Level AA success criteria may not apply to conventional electronic documents and mobile apps directly as written, but the Department declines to set forth exceptions to these success criteria in subpart H… Public entities generally must ensure that the web content and content in mobile apps they provide or make available conform to the WCAG 2.1 Level AA success criteria, to the extent those criteria can be applied.”

Source 28 CFR § Paragraph 402

“To the extent those criteria can be applied” clearly calls out that not all WCAG 2.1 AA success criteria are applicable to make an electronic document compliant with ADA Title II.

Footnote 72 notes that certain criteria “do not appear to be directly applicable to non-web information and communications like conventional electronic documents.”

Source 28 CFR § Paragraph 402 Footnote 72

WCAG2ICT Guidelines – What is the WCAG2ICT and Why Does It Matter?

The WCAG 2 to Non-Web Information and Communications Technologies (WCAG2ICT) “…describes how the Web Content Accessibility Guidelines (WCAG) versions 2.0 [WCAG20], 2.1 [WCAG21], and 2.2 [WCAG22] principles, guidelines, and success criteria can be applied to non-web Information and Communications Technologies (ICT), specifically to non-web documents and software. It provides informative guidance (guidance that is not normative and does not set requirements).”

The key to note is, WCAG2ICT is not normative (also noted as informative), meaning these guidelines for non-web information and communications technologies are not black or white—compliant or not compliant.

For clarity reasons, it is important to understand the definitions of Normative, Informative, and Conformance.

The W3C defines “normative” as:

“Required for conformance

Note 1: One may conform in a variety of well-defined ways to this document.

Note 2: Content identified as "informative" or "non-normative" is never required for conformance.”

Source: W3C—WCAG2ICT, Section 6: Normative Definition

The W3C defines “informative” as:

“for information purposes and not required for conformance.

Note: Content required for conformance is referred to as ‘normative.’”

Source: W3C—WCAG2ICT, Section 6: Informative Definition

Finally, the WCG defines “conformance” as:

“satisfying all the requirements of a given standard, guideline or specification”

Source: W3C—WCAG2ICT, Section 6: Conformance Definition

These definitions and information clearly outline that the DOJ is pointing public entities in the direction of the WCAG2ICT guidelines that do not have a clear set of requirements. The purpose and the goal of these guidelines are to make non-web content as accessible as possible—not setting explicit rules, but allowing for subjectivity and acting in good faith to the overall accessibility mission.

The W3C explains that not all success criteria apply equally to non-web formats:

“Since this document does not specifically say which criteria can or should apply, those implementing this document (WCAG2ICT) should consider the applicability of individual success criteria to non-web documents and software.”
Source: W3C — WCAG2ICT, Section 2.1: Interpretation of Web Terminology in a Non-Web Context

WCAG 2.1 AA Success Criteria – What are They and How are They Measured?

The full list of WCAG 2.1 AA success criteria can be found in the How to Meet WCAG Quick Reference Guide

When running accessibility checkers on PDFs, the most common “failure” under the POUR (Perceivable, Operable, Understandable, Robust) framework occurs under:
1.4.3 — Contrast (Minimum) — Level AA. However, these “failures” do not explicitly mean “non-accessible” in electronic documents such as PDFs. These are often due to the underlying document itself and can, and should, not be altered in any way during the remediation process to ensure the document is retained as an original document. The main compliance standard to measure against in the instance of a failed 1.4.3—Contrast Minimum is that the document’s text and information is still accessible for assistive technology to articulate to the user. OCR, logical reading order, correct and accurate tagging all must be completed for compliance purposes.

Learn more about SC 1.4.3 Contrast (Minimum) or review an overview of Contrast (Minimum) (Level AA).

Electronic Documents, Scanned Images & Contrast Ratio

When a physical document is scanned, it becomes a bitmap image—a photo of text, not actual text. Under WCAG logic, before OCR, that content is an image of text. After OCR, a text layer exists behind or above the image, which means the document should be evaluated differently.

Accessibility checkers like Adobe Acrobat or axes4 often flag “Low Contrast” errors because they can’t tell whether:

• the text is actual, selectable text, or
• just pixels inside an image.

Under WCAG 2.1 AA and the DOJ’s guidance (“to the extent those criteria can be applied”), this type of automated “failure” isn’t a violation if:

• users can still access the OCR text, and
• the scanned background doesn’t obscure or confuse the readable content.

For more on “images of text,” see WCAG SC 1.4.5 — Images of Text

Conclusion

In summary, ADA Title II’s final rule under Subpart H makes one thing clear: accessibility compliance is about functional access, not mechanical perfection. Automated checkers like Acrobat, axes4, and PowerPDF play an important role in identifying technical issues, but they do not determine compliance under WCAG 2.1 AA or the ADA. The DOJ has acknowledged that many WCAG 2.1 success criteria don’t translate cleanly to conventional electronic documents—and therefore must be applied only “to the extent they can be applied.” When a document allows users with disabilities to access the same information with substantially equivalent timeliness, privacy, independence, and ease of use, it meets the spirit and letter of ADA Title II. Accessibility, in practice, depends on thoughtful remediation, accurate tagging, logical structure, and good-faith implementation—not on a pass/fail score from an automated compliance checker.

Legal Disclaimer:
This article is provided for informational and educational purposes only and does not constitute legal advice. Compliance obligations under the ADA, Section 508, and WCAG may vary based on specific circumstances. Readers should consult qualified legal counsel to obtain advice with respect to any particular legal matter.