Matterhorn 26-002 · PDF/UA-1 UA1:7.16-1
The permission bit that blocks screen readers
Bit 10 of the permissions flags is the "extract for accessibility" permission. Clearing it tells assistive technology it may not read the file.
The condition, as the protocol states it. “The file is encrypted and does contain a P entry but the 10th bit position of the P entry is false.”
Matterhorn Protocol 1.1, checkpoint 26, index 26-002, section UA1:7.16-1. Software can decide this one on its own.
What a screen reader actually does
A conforming reader refuses to read the document. This single bit can make an otherwise perfect file completely inaccessible.
One bit
The encryption dictionary carries a /P entry: a 32-bit integer whose bits are permission flags.
<< /Filter /Standard
/V 4 /R 4
/P -1852 % bit 10 clear: no extraction for accessibility
/O <...> /U <...>
>>Bit 10 is “extract text and graphics in support of accessibility to users with disabilities or for other purposes”. Clear it and a conforming processor must refuse to hand the text to assistive technology.
Everything else about the document can be perfect — a complete structure tree, a correct reading order, alt text on every image, a document language — and none of it reaches the user. PDF/UA-1 clause 7.16 therefore requires the bit to be set on any encrypted file.
Condition 26-001 is the related case: the file is encrypted and has no /P entry at all, so there is no declaration either way.
How this happens
Almost never on purpose. Three routes account for most of it:
A “protect document” step in a workflow. Someone ticks Restrict editing in Acrobat or a document management system, and the default permission set clears bit 10 along with printing and copying.
An old preset. Security policies created before accessibility was on anyone’s checklist, still being applied a decade later.
Confusing copy protection with security. Bit 10 is not a security control. Anyone who can see the page can retype it, photograph it, or run OCR over it. What it reliably stops is a screen reader.
How to check it free
Acrobat, any edition including Reader: File → Properties → Security tab. Look for Content Copying for Accessibility. Not Allowed is the failure.
pdfinfo (Poppler, free):
$ pdfinfo -upw '' secured.pdf | grep -i accessib
Accessible: noqpdf (free):
$ qpdf --show-encryption secured.pdf
...
accessibility: not allowedHow to fix it free
If you own the document, in Acrobat Pro:
File → Properties→ Security tab.- Security Method → if it is Password Security, click Change Settings.
- Tick Enable text access for screen reader devices for the visually impaired.
- Or, better, set Security Method to No Security if the encryption was not serving a real purpose.
- Save.
With free tools, if you have the owner password:
qpdf --decrypt --password=OWNERPASS secured.pdf accessible.pdfIf you do not own it, the fix is a conversation, not a tool. Ask the originator to re-issue it. Taggart will not strip protection it was not given the password for, and neither should anything else.
Where Taggart differs
Taggart reports the state plainly:
The file is encrypted and the permissions flags do not allow content extraction for accessibility (bit 10 of /P). Conforming assistive technology will refuse to read this document.
Because permissions live in the encryption dictionary, which is rewritten on save, the repair is a property of the export rather than an edit to an object: with the fix requested, the remediated file is written without the restriction that blocked accessibility, and the change log records it as such. Taggart only does this for files it can already open — it decrypts nothing.
It is worth saying what this condition is not. A file failing 26-002 is not a badly tagged file. It may be flawlessly structured. The single bit is enough on its own, and it is the cheapest fix on this entire site: one checkbox, and the document goes from unusable to fine.
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 is mechanical, so “Fix All Safe” applies it in bulk with a diff and a single undo.
Whatever Taggart changes, the page still looks identical. Fixes edit the PDF object model, not the content streams, and every remediation is re-rendered and compared against the original at structural similarity ≥ 0.999 before you get the file back. A tool that quietly reflows your document is worse than no tool.
Frequently asked questions
Which bit is it?
Bit position 10 of the /P entry in the encryption dictionary, counting from 1 as ISO 32000-1 Table 22 does. In Acrobat's UI it is the checkbox labelled 'Enable text access for screen reader devices for the visually impaired'.
Do readers actually honour it?
Conforming ones do. Acrobat honours it, and so do the assistive technologies that go through Acrobat's API. Some third-party tools ignore it, which means the file's behaviour depends on which software the user happens to have — which is its own accessibility failure.
Can I clear it without the owner password?
You should not, and Taggart will not. Removing a restriction you were not given the password for is circumventing a technical protection measure, whatever you think of the restriction. The fix is to go back to whoever encrypted the file.
Should I encrypt an accessible PDF at all?
You can, and it can conform. PDF/UA-1 does not forbid encryption; it requires that if the file is encrypted, extraction for accessibility is permitted. In practice, if the only reason for the encryption is to discourage copying, it costs you more in accessibility and interoperability than it buys.
Where this sits in the standards
| Standard | Reference |
|---|---|
| Matterhorn Protocol 1.1 | Checkpoint 26 (Security), index 26-002 |
| PDF/UA-1 (ISO 14289-1) | Clause 7.16-1 |
| WCAG 2.1 | 1.3.1 Info and Relationships — Level A |
| EN 301 549 / Section 508 / ADA Title II | All three point at WCAG 2.1 Level AA for non-web documents, so a Level A or AA criterion here is in scope for each of them. |
Related conditions
- 26-001 The file is encrypted but does not contain a P entry in its encryption dictionary Without a /P permissions entry there is no declaration that content may be extracted for accessibility.
- 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.
- 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.
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.
Check your own file. Taggart’s validator is free and unlimited — every machine-checkable Matterhorn condition, no page cap, no watermark, no account needed.
Verified against a real document on . Last updated .