Free PDF accessibility checker:
check PDFs online against PDF/UA

What a PDF accessibility checker can and cannot check

A PDF accessibility checker reads the layer beneath the visible page: the tags that tell a screen reader what is a heading, a list, a table or a form field, in which order the content comes and in which language. PDF/UA (ISO 14289-1) defines how this layer must be built. Some of its requirements are mechanical, and software can test them reliably; others need a person. The Matterhorn Protocol of the PDF Association draws exactly this line.

Software can tell whether a document is tagged, whether a language is set or whether a form field lacks a label. It cannot tell whether an alternative text actually helps, whether the order of the content makes sense to someone who cannot see the layout, or whether color alone carries information. Across WCAG, 60–70 % of the success criteria cannot be tested automatically. Access Read does not pretend to judge such points; it flags anything that needs human judgment for manual review.

The most common findings and what they mean

A poor result usually comes down to a few recurring problems, each with a concrete effect for screen reader users:

• Tags and headings. An untagged PDF reaches a screen reader as an unstructured stream of text, or not at all. Headings tagged as plain paragraphs remove the fastest way through a long document; levels that jump from H1 to H4 break its outline.
• Reading order. A screen reader follows the order of the tags, not the layout. Columns, sidebars, text boxes and footnotes often land in the wrong place. The read-aloud view in Access Read shows this order the way a screen reader presents it.
• Tables. If header cells are not marked as headers, or layout grids are tagged as data tables, values are read out without their row or column. An amount means nothing without its month or account.
• Form fields. A field without a label is announced as a generic edit field. Nobody hears whether a name, a date or an account number belongs there.
• Language. Without a correct document language, the speech synthesizer pronounces English with German rules, or the other way around. Foreign-language passages need their own marking.
• Artifacts. Page numbers, running headers and decorative lines should be marked as artifacts so that a screen reader skips them. The reverse error is worse: real content marked as an artifact disappears for assistive technology. Access Read reports it as a finding.

How to read the 0–100 index honestly

The index condenses the machine-testable part of the check into one number. The FAQ above groups it into three bands: 95–100, 60–94 and 0–59. This is how I read it:

• A low index is a reliable warning. If the technical basics fail, good wording will not rescue the document.
• A high index is necessary, not sufficient. The check found few technical problems; nobody has yet confirmed that the alternative texts make sense or that the reading order follows the argument. The top band is where human review starts.
• The findings matter more than the number. Access Read shows how often each issue occurs. An error that appears hundreds of times usually has one cause, often a template or an export setting. Fix the cause, and the number follows.
• Do not optimize for the number. Errors can be made to vanish without helping anyone, for example by hiding content from assistive technology.

From check to fix: Access Doc

The best fix starts in the source file: real heading styles instead of manual formatting, tables with a defined header row, alternative text for images, a document language. Fix the template once, and every future export benefits.

For PDFs that already exist, such as archives or files whose source is lost, this is the job of Access Doc: we remediate PDFs to PDF/UA, with a human review of everything software cannot judge, from a single contract to large document volumes, and with a conformance report for each document. Afterward, check the result with Access Read.

For US documents: Section 508 and ADA Title II

Legal status as of November 10, 2026 (this section and the next).

Section 508 and ADA Title II ask for WCAG, not for PDF/UA. The Revised 508 Standards require the electronic content of federal agencies, including non-web documents such as PDFs, to conform to WCAG 2.0 Level A and AA. PDF/UA appears there only as a requirement for authoring tools that export PDF, not as an alternative way to conform. Vendors are affected through procurement. More on our Section 508 page.

Under ADA Title II, the 2024 rule of the Department of Justice requires WCAG 2.1 Level AA for the web content of state and local governments, explicitly including PDFs. An interim final rule of April 20, 2026 moved the deadlines to April 26, 2027 (population of 50,000 or more) and April 26, 2028 (smaller entities and special districts). The National Federation of the Blind has challenged the delay in court; no decision is known yet. Older documents are exempt only within limits, for example not while people still use them to apply for or access a service. Details on our ADA Title II page; for private businesses under Title III, where no regulation sets a technical standard, see the US overview.

For a PDF check, this means: PDF/UA lays much of the technical groundwork for WCAG in a PDF, but a PDF/UA check covers only the machine-checkable part, not everything WCAG asks for. A good Access Read result is a solid first step, not proof of Section 508 or ADA conformance. Is there such a thing as an “ADA-compliant PDF”? Our answer: ADA and Section 508 PDFs: what the rules actually require.

For EU documents: EAA, BFSG and PDF/UA

Since June 28, 2025, the European Accessibility Act has applied to consumer services such as e-commerce and banking, through national laws like the German BFSG. It also reaches non-EU companies that offer such services to consumers in the EU (see our EAA guide). Office file formats such as PDFs are exempt only if they were published before June 28, 2025; how far the requirements reach for documents published since then as part of a covered service is not yet settled. Public sector bodies have had to include documents under the Web Accessibility Directive for years, with a limited exemption for office files published before September 23, 2018.

On the technical side, EN 301 549 is the reference, and its chapter on non-web documents builds on WCAG. Version 3.2.1 (WCAG 2.1 Level AA) is harmonized under the Web Accessibility Directive. Version 4.1.1 (WCAG 2.2 Level AA) was published on September 2, 2026; the Irish National Disability Authority expects it to be cited in the Official Journal in December 2026. Under the EAA, no standard has been cited yet. Here, too, PDF/UA is not the legal yardstick, but in practice it is how a PDF meets many of these requirements. More in our EN 301 549 guide.

In both markets, a PDF accessibility checker shows you the technical state of a document, and Access Read does it free of charge: the first step, not the verdict. For the full path from source file to finished document, read our guide to PDF/UA-compliant documents.