← Back to the PDF Accessibility Tag Checker
Because PDF/UA and Section 508's tagging requirement is about a structure tree stored inside the file, not about how the page renders. A PDF viewer paints a page from raw drawing instructions -- position this text run here, draw this image there -- and can produce a perfectly readable page with no structure tree at all. A screen reader does not see the rendered page; it reads the tag tree, and if that tree is missing, incomplete, or never marked current, there is nothing for it to read regardless of how the page looks to a sighted reviewer.
This gap is why a document can pass every eyeball review a team gives it and still fail a structural check outright: the two are looking at different things. Below is what each of this tool's six findings actually means and, where there is one, the ordinary fix.
The document catalog has no /StructTreeRoot at all, or has one but never declares
/MarkInfo /Marked true -- so a reader cannot trust that whatever tree exists is complete
or current. This is by far the most common finding, because tagging is opt-in at export time in most
authoring tools: a Word document saved as PDF without "Best for electronic distribution and
accessibility" checked, or a design tool's PDF export run without its accessibility pass, both produce
a visually normal document with nothing structural underneath. The fix happens upstream, at export --
in Word, Export > Options > "Document structure tags for accessibility"; in Acrobat Pro, the
Accessibility > "Autotag Document" or "Make Accessible" wizard adds a tree to a PDF that already
exists.
Both are single dictionary entries -- /Title in the Document Information dictionary,
/Lang in the document catalog -- and both are invisible in a normal read-through because
neither one renders on the page. Without a title, a screen reader announces the file name instead
(scan0047.pdf is not useful to anyone); without a declared language, assistive
technology has no signal for which pronunciation rules to load, even in a document written entirely
in one language throughout.
The page you see is usually a scanned image of a printed document, not real text -- common for signed forms, older records, and anything run through a copier before being saved as a PDF. Visually the words are sharp and legible; structurally the page is one large picture with no text-show operator anywhere in its content stream, so nothing can be selected, searched, copied, or read aloud. The fix is OCR: running the page through optical character recognition to add a real, invisible text layer underneath the image.
A partial-alt-text finding is document-wide: it counts every image in the file against every
non-empty /Alt string found anywhere in the structure tree, because matching a specific
alt-text entry to the exact image it labels needs the marked-content ID chain this tool does not
walk. If the counts are close, most images are likely labelled and a manual pass can confirm which
ones are not; if the alt-text count is far below the image count, most images still have nothing,
even though the file clearly has alt text on some of them.
An interactive form field can look perfectly labelled on the page -- a text box sitting right next to
the words "Last name" -- while carrying no /TU (alternate field name) on itself or any
ancestor field. The visible label and the field are two separate objects with no structural
connection between them; a sighted user's eye makes the association a screen reader cannot. The fix
is setting each field's tooltip/alternate name in the PDF form editor so the connection exists in the
file, not just on the page.
Drop a PDF into the checker to see exactly which of these findings apply to it, with the specific evidence behind each one, or scan a whole folder at once with the CLI:
node cli/check.mjs ./document-library/ --jsonNeither the browser page nor the CLI uploads the file anywhere -- see the disclaimer below.