Matterhorn 26-001 · PDF/UA-1 UA1:7.16-1

A secured PDF that never granted permission to read it aloud

Without a /P permissions entry there is no declaration that content may be extracted for accessibility.

What a screen reader actually does

Conforming readers may refuse to extract text from the document at all.

What is in the file

An encrypted PDF has an encryption dictionary in its trailer. Among its entries is /P — a signed integer whose bits are permissions:

/Encrypt << /Filter /Standard /V 4 /R 4 /P -1340 ... >>

Bit 5 is copy or extract text and graphics. Bit 10 is extract text and graphics for accessibility. They are deliberately separate: the format’s authors intended a document to be able to forbid casual copying while still permitting assistive technology.

This condition fires when the file is encrypted and /P is absent altogether. There is no statement either way, and a conforming processor that looks for permission and finds no grant has been given nothing to rely on.

What the user hears

Possibly everything. Possibly nothing. The variation is the problem.

Most desktop screen readers ignore the permission bits. JAWS and NVDA on Windows, VoiceOver on macOS — all generally read a document the user has legitimately opened. On those, the file works.

Conforming processors behave differently, and so do a number of things that are not screen readers but matter just as much: enterprise document conversion pipelines, some mobile readers, text-extraction libraries used by downstream systems, and the accessibility validators that decide whether the document passes. Those honour the declaration, and with no declaration they decline.

The result is a document that works on the machine it was tested on and silently fails in the place it was sent to — which is the worst shape a defect can take, because nobody can reproduce it and the person reporting it is not believed.

Where it comes from

Protection applied as a habit. A great deal of PDF security exists because a menu item was there, not because anyone decided the document needed it. Somebody applied Restrict Editing years ago and the setting has been inherited through every revision since.

Old encryption written by older tools. /P has been part of the standard encryption handler for a long time, but tools that assembled encryption dictionaries by hand, or copied one from another file, sometimes omitted it.

Pipelines that re-encrypt. A document that passes through a rights-management or watermarking step and comes out encrypted by something other than the tool that made it.

How to check it free

Acrobat. File → Properties → Security tab. The Document Restrictions Summary lists each permission; look for Content Copying for Accessibility. Not Allowed is the related condition 26-002; a file with no /P at all usually shows the whole panel in an unhelpfully permissive state.

Command line, and this is the clearer answer:

qpdf --show-encryption document.pdf

It prints the permission bits it finds, including whether accessibility extraction is allowed, and says plainly when the file is not encrypted at all.

veraPDF reports it against clause 7.16.

How to fix it free, in Acrobat Pro

If the protection is not doing anything — and check this before anything else, because it usually is not:

1. File → Properties → Security.
2. Security Method → No Security.
3. Save.

If the protection is deliberate, keep it and grant the permission:

1. File → Properties → Security → Security Method → Password Security.
2. Under permissions, set Changes Allowed as you need it.
3. Tick Enable text access for screen reader devices for the visually impaired.
4. Save.

That checkbox is the one that matters, it is distinct from Enable copying of text, and it is off by default in some workflows. A document can forbid copying and permit reading aloud, which is exactly what most people who apply protection actually want.

qpdf, free and scriptable, for a backlog:

qpdf --decrypt in.pdf out.pdf

Where Taggart differs

It distinguishes this from 26-002, which is the file that forbids extraction, and the distinction is harder than it looks: the usual library answer reports a default when /P is absent, so “not permitted” and “nothing was said” come back identical. Taggart reads the encryption dictionary rather than the library’s interpretation of it, because those are two different documents to hold and two different conversations to have with whoever produced them.

accessibility-permissions is a safe fix and runs in the batch, and what it does is worth stating precisely because “we changed your document’s security” deserves no ambiguity.

Taggart writes the output unencrypted, and says so in the change log rather than leaving it to be discovered. That is the only repair that can honestly promise what this fix promises: an output that no longer carries a restriction blocking extraction. Re-encrypting with a corrected /P would require a password Taggart does not have and must never invent.

So the remediation report records it as a change to the document’s security, in those words:

removed encryption; the source file was encrypted with no /P entry, so no accessibility-extraction permission was declared

If that is not acceptable for a particular document — and for some it will not be — the finding stays open and the file keeps its encryption. Taggart will not quietly strip protection from a document and report it as a metadata fix.

How Taggart handles it

Taggart detects this condition automatically. It is reported as a blocker, with the page, the structure path and the object id of every occurrence.

The fix is Grant accessibility extraction permission. It changes what the document means, so Taggart proposes it and waits for your approval rather than applying it unattended.

Where this sits in the standards

Related conditions

• 26-002 The 10th bit position of the P entry is false Bit 10 of the permissions flags is the "extract for accessibility" permission. Clearing it tells assistive technology it may not read the file.
• 10-001 Character code cannot be mapped to Unicode A glyph is painted whose character code has no Unicode equivalent reachable through the font's ToUnicode CMap, encoding, or glyph names. The text renders correctly but cannot be extracted.
• 01-005 Content is neither marked as Artifact nor tagged as real content Every text-showing, image-painting and path-painting operator on a page must sit either inside a marked-content sequence that maps to the structure tree, or inside an artifact sequence. Content that is in neither is orphaned.
• 07-001 ViewerPreferences does not contain DisplayDocTitle Without /DisplayDocTitle the viewer is free to show the filename in the window title instead of the document title.

Other conditions in checkpoint 26

Checkpoint 26 covers security. These are its other failure conditions; the ones without a link are in the rule set but do not have a written page yet.

• 26-002 The 10th bit position of the P entry is false Bit 10 of the permissions flags is the "extract for accessibility" permission. Clearing it tells assistive technology it may not read the file.

Verified against a real document on 2026-09-13 . Last updated 2026-09-13 .