PDF Accessibility Checker (PDF/UA)

About the PDF Accessibility Checker (PDF/UA)

Check how accessible a PDF is for people who use screen readers, magnifiers or keyboards. The tool runs the checks that software can decide from PDF/UA (ISO 14289-1:2014, the accessibility standard for PDF) and groups them by the checkpoints of the PDF Association’s Matterhorn Protocol: whether the file is tagged, its language and title, alternative text on figures, the order of heading levels, table header cells, tagged links, comments and form fields with names, tab order, embedded fonts that map to Unicode, scanned pages without text, bookmarks and security settings that could block assistive technology.

Each result says what was found, on which pages, and how to fix it. Three safe fixes can be applied straight away — the document title, the language and showing the title instead of the file name — and the fixed copy is checked again. Some things only a person can judge (reading order, whether alternative text makes sense, colour contrast), so they are listed for you to review; passing every check here is not a compliance certificate. The file is checked in your browser and never uploaded.

Common uses

• Checking documents before publishing them on a government, university or company website.
• Testing PDFs exported from Word, PowerPoint, InDesign or LibreOffice before sending them out.
• Finding what to fix first in a large set of legacy documents.
• Giving a screen-reader user’s complaint a concrete cause (missing tags, no language, unnamed form fields).

What is checked

• 01 Real content tagged — a structure tree exists, the file is marked as tagged, and no text, image or graphic is outside the tags or decoration (artifacts).
• 02 Role mapping — custom tag types map to standard ones, without loops.
• 06 Metadata / 07 Dictionary — XMP metadata with a title, the PDF/UA identifier, and the title shown instead of the file name.
• 08 OCR validation — pages that are only a picture (scans without text).
• 10 Character mappings / 31 Fonts — fonts used are embedded and map their characters to Unicode, so text can be read out and copied.
• 11 Declared natural language — a valid document language.
• 13 Graphics / 17 Mathematical expressions — figures and formulas have alternative text.
• 14 Headings — numbered headings start at H1 and don’t skip a level.
• 15 Tables — tables are built of rows and cells, with header cells that have a Scope or point to valid IDs.
• 19, 20, 21, 25, 26, 30 — notes have IDs, layers are named, attachments have file names, no dynamic XFA, screen readers allowed to read the text, no reference XObjects.
• 27 Navigation — bookmarks (WCAG technique PDF2); this tool warns when a document of more than 20 pages has none — a rule of thumb, as WCAG sets no page count.
• 28 Annotations — comments, links and form fields are tagged, have descriptions and names, and the tab order follows the structure.

What software can’t check

Many PDF/UA and WCAG requirements need judgement: whether the reading order is right, whether alternative text describes the picture well, whether headings and lists are tagged as what they are, whether colours have enough contrast (at least 4.5:1 for normal text in WCAG 2.2), and whether link text makes sense. The report lists these so you can go through them with a screen reader such as NVDA or VoiceOver, or with a PDF accessibility editor. A document can pass every machine check and still be hard to use.

PDF/UA, WCAG and the law

PDF/UA (ISO 14289-1:2014) defines what an accessible PDF file must contain; the Matterhorn Protocol from the PDF Association breaks it into 31 checkpoints with 136 failure conditions, some testable by software and some only by people. WCAG 2.2 (W3C) applies to PDFs through its PDF techniques. Laws refer to these standards: in the EU, EN 301 549 V3.2.1 clause 10 covers documents that aren’t web pages; in the US, the Section 508 standards (36 CFR Part 1194) apply WCAG 2.0 Level AA to federal electronic content, and the Department of Justice’s ADA Title II rule (28 CFR Part 35, Subpart H) requires WCAG 2.1 Level AA for state and local government web content, including PDFs, from April 26, 2027 for governments of 50,000 people or more and April 26, 2028 for smaller ones and special districts (dates as extended in April 2026). Whether a rule applies to your documents depends on who you are and where — this page is not legal advice.

The quick fixes

Title — writes the title to the document information and to the XMP metadata (dc:title), creating the metadata if the file has none; other metadata is kept. Language — sets the document language (/Lang) used by screen readers to pick a voice and pronunciation. Show the title — sets DisplayDocTitle so readers show the title, not the file name. Nothing else in the file changes; tags and content can only be fixed in the program that made the document or in a PDF accessibility editor.

Sources

• ISO 14289-1:2014, Document management applications — Electronic document file format enhancement for accessibility — Part 1: Use of ISO 32000-1 (PDF/UA-1); clause numbers as in the veraPDF PDF/UA-1 rules.
• The Matterhorn Protocol (PDF Association): 31 checkpoints, 136 failure conditions.
• W3C, Web Content Accessibility Guidelines (WCAG) 2.2, and PDF Techniques for WCAG (e.g. PDF2, bookmarks).
• RFC 3066, Tags for the Identification of Languages — the form of the document language (veraPDF rule 7.2-29): a 2- or 3-letter ISO 639 code such as en or hi, optionally followed by a region such as -IN.
• ETSI EN 301 549 V3.2.1, clause 10 — non-web documents.
• US Access Board, Section 508 standards, 36 CFR Part 1194.
• US Department of Justice, ADA Title II web and mobile accessibility rule, 28 CFR Part 35, Subpart H, compliance dates as extended by the interim final rule (ada.gov).

Limitations

• Only machine-checkable requirements are tested, and not all of them: for example list structure, the exact reading order and the meaning of tags need other tools or a person.
• The font checks look at the fonts the page content uses; whether every single glyph has a correct Unicode value can’t be fully verified without the font’s glyph data.
• The tool doesn’t add or repair tags: correct tags need knowledge of the content. Use the authoring program’s accessible PDF export, or a PDF accessibility editor.
• Fixes can’t be saved into password-protected or restricted PDFs; unlock them first with Unlock PDF.
• Saving the fixed copy rewrites the file, which invalidates existing digital signatures.
• The first use downloads the PDF engines once, so it needs an internet connection.

Privacy

Everything happens in your browser. What you enter or open here is not uploaded or stored by MySmartCoPilot.