How to make a PDF accessible: what actually has to change

Making a PDF accessible means adding the invisible structure a screen reader
needs: tags that identify headings, lists, and tables; a correct
reading order; alt text for images; a set document language and
title; and navigable tables. You can do all of it by hand in Adobe
Acrobat Pro — this guide shows what each step involves — or automate the bulk
of it. Either way, the checklist is the same, and knowing it helps you judge
any tool or vendor you consider, including us.

Start with the biggest question: is it a scan?

Open the PDF and try to select a sentence with your cursor. If you can't —
if the page is effectively a photograph — you have a scanned document,
and no amount of tagging helps until it contains real text. That means OCR
(optical character recognition) first, then structure. For most small
districts, scans are the majority of the backlog: decades of board minutes
went through a copier, not a word processor. Budget your effort accordingly:
a born-digital PDF might need twenty minutes of cleanup; a long scan can need
several times that. (One carve-out worth knowing: scans that live in a true
digital archive may fall under the
archived-content exception —
check before you remediate a closed collection.)

Tags: the document's skeleton

Accessible PDFs carry a tag tree — a machine-readable outline that tells
assistive technology what each piece of content is: this is a first-level
heading, this is a paragraph, this is a list with five items, this is a
table. Sighted readers infer structure from size and bold; a screen reader
can only use tags. (This is the document-level version of what
ADA Title II asks of
your whole web presence.)

In Acrobat Pro, the work lives in the Accessibility tools and the Tags panel:
run "Autotag Document," then walk the tree correcting what it guessed —
headings tagged as plain paragraphs, tables tagged as pictures, decorative
flourishes tagged as content. Autotagging gets you a draft, not a result; on
complex layouts (newsletters, multi-column agendas) expect substantial manual
correction.

Reading order: what a screen reader hears first

Tags say what content is; reading order says what sequence it arrives
in. A two-column newsletter that reads straight across both columns produces
word salad. In Acrobat, the Reading Order tool shows numbered regions you
drag into sequence — tedious on long documents, and one of the most common
places automated tagging goes wrong, so always check it.

Alt text: describe what matters

Every image that carries meaning needs alt text — a short written
description a screen reader speaks in its place. The craft is judgment, not
grammar: a chart's alt text should say what the chart shows ("General fund
spending rose from $1.2M to $1.4M between 2024 and 2026"), not what it is
("bar chart"). Purely decorative images should be marked as artifacts so
screen readers skip them entirely. This judgment step is exactly where
automation is weakest and where a human eye matters most.

The five-minute fixes: language, title, bookmarks

Three properties take minutes and are routinely missing:

• Document language (File → Properties → Advanced) — without it, a screen
  reader may pronounce English text with the wrong speech engine entirely.
• Document title (File → Properties → Description, plus showing the title
  instead of the filename in Initial View) — otherwise users hear
  "minutes_FINAL_v3 (2).pdf".
• Bookmarks for long documents — the navigation pane equivalent of a
  table of contents.

Tables: headers, not just grids

A table is accessible when its header cells are tagged as headers and
associated with their rows and columns, so a screen reader can answer "what
column am I in?" from any cell. Merged cells, nested tables, and layouts that
use tables for visual arrangement all multiply the work — in Acrobat this is
cell-by-cell work in the table editor. Budget documents are usually where
this bites hardest.

Checking your work

Acrobat's built-in Accessibility Checker catches the mechanical problems.
The stricter test is validation against PDF/UA, the ISO standard for
accessible PDFs, using veraPDF — the open-source
validator the industry treats as the referee. Two honest caveats: a passing
veraPDF check proves the structure is present and well-formed, not that your
alt text is good — that's human judgment; and a failing check tells you
precisely what to fix. Validate, fix, repeat.

By hand or automated: an honest comparison

Everything above is genuinely doable by hand with Acrobat Pro and patience.
The math is the hard part: at even 20–40 minutes per document, a backlog of
400 PDFs is roughly 150–250 hours of skilled, tedious work — and it recurs
with every agenda you publish. That's the shape of problem automation is for:
let software rebuild tags, reading order, and properties in minutes, keep
humans on the judgment calls like chart descriptions.

That division of labor is exactly how Ketchly works —
automated remediation to the PDF/UA standard, veraPDF validation on every
document, and human review where the AI isn't confident. If the checklist
above is the "what," and the April 2028 deadline
is the "when," the remaining question is only whether the "how" is your
evenings or a subscription.