About PDF accessibility

A PDF can look completely ordinary — clean layout, readable headings, a sensible-looking table — and still be close to unusable for someone using a screen reader. That gap is the whole reason PDF accessibility remediation exists as its own discipline, and it’s worth understanding why the gap is even possible before looking at what Content Studio does about it.

Two separate things that happen to look the same

A PDF’s visual layout and its semantic structure are, technically, two different things layered on top of each other. The visual layout is the ink on the page: text positioned at coordinates, lines, shapes, images placed where a designer put them. A sighted reader doesn’t need anything else — position, font size, and spacing are enough to infer that a large bold line is a heading, that a paragraph reads left to right and top to bottom, that a grid of numbers is a table with these rows and these columns. None of that inference is available to a screen reader. It doesn’t see position or size; it needs the same information encoded explicitly, in a separate layer of tags: which text is a heading and at what level, what order the content should be read in, which cells belong to which row and column, and what an image is actually depicting via alt text. A PDF can have beautifully arranged ink and no such layer at all — and plenty of PDFs, especially ones exported straight from a design tool, are exactly that. It renders identically to a well-tagged PDF and behaves nothing like one under assistive technology.

This is also why remediation is a different task from editing a PDF’s content. Editing changes what’s printed on the page. Remediation changes what the document means to a screen reader, without touching what’s printed at all.

Why Content Studio preserves the visual document

Content Studio’s PDF tool never changes how a document looks. It only adds and fixes the invisible layer — reading order, heading structure, table relationships, alt text, tags — that assistive technology relies on. This is a deliberate constraint, not just a technical convenience, and it matters for a reason that’s easy to miss if you haven’t been through a document approval process: a PDF that looks exactly the same after remediation as it did before doesn’t need to go back through whoever signed off on the original design. Brand, legal, or a client approved a specific visual document; if remediation is guaranteed to be pixel-identical, that approval still holds. If remediation could shift layout or rewrite content, every remediated file would need a second round of visual sign-off — which in practice means either that step gets skipped (and a quiet mistake ships) or accessibility work gets stuck behind a review queue that has nothing to do with accessibility. Keeping the visual layer immutable is what makes remediation something you can run on an already-approved document with confidence.

The standards this maps to

PDF accessibility is typically verified against PDF/UA-1, the technical standard for what a “properly structured” PDF actually requires at the format level — tag tree correctness, reading order, table markup, and so on. An audit against PDF/UA-1 is a check on the invisible layer described above, not on how the document looks — which is consistent with the whole approach: the thing being verified is exactly the thing that was added.

Where this connects

For the mechanics of running remediation and fixing what an audit flags, see Fix PDF accessibility issues in the editor and Republish a PDF, or start from Remediate your first PDF for a guided first pass. Export formats covers what a remediated PDF export actually contains, and unfamiliar terms are collected in the Glossary of terms. For how screen readers and other assistive technology actually use this structure, see About assistive technology.