PDF Accessibility (PDF/UA) Quick Check

Laden Sie das PDF oben hoch - die Prüfung startet sofort und läuft vollständig in Ihrem Browser. Geprüft wird, ob das Dokument getaggt ist, ob ein Strukturbaum vorhanden ist, ob eine Dokumentsprache und ein Titel gesetzt sind, ob der Titel statt des Dateinamens angezeigt wird, ob die PDF/UA-Kennung in den XMP-Metadaten steht und ob alle Bilder einen Alternativtext haben. Jedes Ergebnis wird in verständlicher Sprache erklärt, inklusive der Auswirkung auf Screenreader-Nutzer. Kostenlos, ohne Anmeldung und ohne Windows-Download - im Gegensatz zum verbreiteten Desktop-Tool PAC.

Déposez votre PDF dans l'outil ci-dessus. Il contrôle les critères structurels que le RGAA et la norme EN 301 549 attendent d'un document PDF : présence des balises (PDF taggé), arbre de structure, langue du document, titre du document et affichage de ce titre à la place du nom de fichier, identifiant PDF/UA dans les métadonnées XMP, et texte alternatif sur les images. Attention : il s'agit d'un contrôle automatique des critères vérifiables par machine. L'ordre de lecture, la pertinence réelle des textes alternatifs et la structure des tableaux nécessitent une vérification humaine.

No, and it doesn't pretend to be. The Matterhorn Protocol - the testing framework PAC implements - defines 136 failure conditions across 31 checkpoints, of which roughly 89 are machine-checkable and about 45 require human judgement. This tool runs the document-level subset plus image alt text: the checks that catch the most common and most damaging problems, and the ones people most often need to verify quickly. For a full conformance audit before publishing at scale, use PAC or another complete PDF/UA validator, and budget for a human review either way.

No. It means nothing obvious is broken at the document level. A PDF can pass every automatic check and still be unusable: the reading order can zig-zag across columns, alt text can say "image1.png" instead of describing the picture, headings can be styled to look like headings without being tagged as any, and table headers can be missing their cell associations. None of those are machine-detectable. Treat a clean result as a green light to do the human review, not as a substitute for it.

Tags are an invisible outline stored alongside the visible page, recording that this block is a level-2 heading, that one is a paragraph, this is a list, that is a table cell. Sighted readers infer all of that from layout - size, spacing, boldness. A screen reader can't see layout, so without tags it just reads characters in whatever order they happened to be drawn, which can jump between columns mid-sentence. Tags are what let a user jump between headings, navigate a table by row and column, or skip a decorative image.

Because they're different things. The PDF/UA identifier is a small declaration in the XMP metadata (pdfuaid:part) saying "this file claims to conform to PDF/UA". Plenty of well-tagged, genuinely accessible PDFs never get that flag written, usually because the tool that produced them doesn't set it. Conversely, a file can carry the identifier and still fail the standard badly - it's a claim, not a proof. It matters because compliance tooling and some assistive technology look for it, so a conformant file should say so.

No. The entire analysis - reading the document catalogue, the XMP metadata, the structure tree and every page's drawing operations - runs locally in your browser. Documents being checked for accessibility are often unpublished reports, contracts or internal files, so nothing is transmitted, logged or stored. You can confirm it by going offline after the page loads: the check still runs.

It reads each page's drawing instructions to find every image actually painted, tracking the marked-content context around it. Then it reads the page's structure tree and links each image back to the tag that owns it via the marked-content id. An image inside a tag carrying an Alt or ActualText entry counts as having a text alternative; one inside a tag with neither is reported as missing alt text; one drawn inside an Artifact marked-content block is reported as decorative, which is correct and expected for borders and background flourishes; and one with no owning tag at all is reported as untagged, which means a screen reader skips it silently.

Usually not - it's often exactly right. Decorative images carry no information: rules, spacers, background shapes, repeated logos in a header. Marking them as artifacts tells a screen reader to skip them, which is better than announcing "image" a dozen times per page. It only becomes a problem if an image that does carry information - a chart, a diagram, a photo the text refers to - has been marked decorative, because then its content is deliberately hidden from screen-reader users. That distinction needs a person to judge.

Yes, though image checking is capped at the first 60 pages so the analysis stays fast and doesn't exhaust memory on a modest machine - and the report says so explicitly when that cap applies. The document-level checks (tagging, structure tree, language, title, PDF/UA identifier) always cover the whole file regardless of length, because they live in the document catalogue and metadata rather than on individual pages.