PDF Accessibility Basics — Making Documents Readable for Everyone

Accessibility is one of those subjects that sounds academic until you watch someone try to use a document and fail. A student using a screen reader hears nothing because a scanned PDF has no text layer. A low-vision reader enlarges a page and discovers the text reflow is broken. A colleague with limited fine motor control cannot click a form field because it has no label. In all of those cases, the document is not broken for most readers — but it is completely broken for the reader it mattered most to.

Making PDFs accessible is not complicated once you know what accessibility tools actually need. This guide walks through the core ideas — tagged PDFs, alt text, reading order, and searchable text — in plain language, and shows the practical steps anyone can take to produce documents that work for more people.

What makes a PDF accessible

A fully accessible PDF carries a few things that most PDFs do not.

A real text layer. The words on the page exist as text, not as an image of text. Assistive technologies like screen readers cannot read a scanned image of a page. They need the words themselves.

Tags describing the structure. A tagged PDF has an internal structure: this is a heading, this is a paragraph, this is a list, this is a table. Screen readers and other assistive tools use those tags to navigate the document.

Alt text for images. Every meaningful image has a short description that explains what it is. "Photo of a student at a desk" or "Chart showing declining energy prices from 2020 to 2025".

A logical reading order. The order a screen reader follows when reading the page matches the order a sighted reader would follow. Columns in the right order. Captions attached to their images. Footnotes read after the paragraph that references them.

Form fields with labels. Every field in an interactive form has a label that tells the user what the field is for.

Accessible color and contrast. Text is legible against its background, and color is not the only way information is conveyed.

A PDF can fail any one of those tests and still look fine to a sighted reader. That is why accessibility problems are often invisible to the author.

Start with an accessible source document

The single biggest accessibility decision happens before the PDF is created. If you write in Word, Google Docs, or another structured authoring tool, using the built-in heading styles, list styles, and table styles produces a document that converts cleanly to an accessible PDF.

Use real headings. A line that looks big and bold because you manually changed the font is not a heading. A line that uses the "Heading 1" style is. Word's style system, Google Docs' heading dropdown, and Notion's header blocks all produce tagged output.

Use real lists. Bullet points created with the bullet-list tool carry list structure into the PDF. Bullet points faked with a dash at the start of each line do not.

Use real tables. A table created with the insert-table tool is a table. A grid faked with spaces and vertical pipes is not.

Add alt text to images. Every major writing tool has an "alt text" or "description" field on images. Fill it in when you insert the image.

Label form fields. If the document will be an interactive form, give every field a clear label.

Convert from a well-structured source and the resulting PDF is most of the way to accessible.

Scanned documents and OCR

Scanned PDFs are the number one accessibility problem. A scan is just a photo of a page, and a photo has no text. Screen readers cannot read it. Search does not work. Copy-paste returns nothing.

The fix is OCR — optical character recognition. OCR analyzes the image, recognizes the characters, and adds an invisible text layer behind the image so that screen readers and search tools can access the words. The OCR explainer covers how the technology works and when it is most useful.

A few points worth knowing:

• OCR accuracy depends on scan quality. Clean, high-resolution, well-lit scans produce near-perfect recognition. Crooked, low-resolution, or low-contrast scans produce errors that need manual correction.
• OCR does not fix tagging, alt text, or reading order. It adds a text layer; it does not add document structure.
• OCR produces a searchable PDF, which is a real step forward, but a searchable PDF is not automatically a tagged PDF. Tagged PDFs are a stronger standard.

For a document that started as a scan, OCR is the mandatory first accessibility step.

Reading order matters more than it looks

A page with two columns has an implicit reading order: top of the left column, bottom of the left column, top of the right column, bottom of the right column. A screen reader does not see "columns". It follows whatever order the PDF describes. If the order in the file is wrong, the screen reader reads the first line of the left column, then the first line of the right column, then the second line of the left column — producing gibberish.

Authoring tools usually get reading order right, but complex layouts — brochures, newsletters, annual reports — often need a reading-order review. Most accessibility tools let you reorder the tags until the reading order matches the visual order. It is not glamorous work, but it is the difference between a usable and unusable document.

Alt text: what to write and what not to write

Alt text is a description of an image that a person cannot see. Write it as though you were describing the image to someone on a phone call.

Good alt text describes the content and the function.

• "Bar chart showing monthly revenue from January to December, with peak revenue in November."
• "Photo of a student using a PDF tool on a laptop."
• "Company logo."

Bad alt text is either useless or redundant.

• "Image." (no information)
• "A chart." (tells the reader nothing about what the chart shows)
• "The image below shows..." (treats the reader like they can see the layout)

Decorative images that carry no information — background patterns, purely ornamental icons — should be marked as decorative so the screen reader skips them. Many tools have a "mark as decorative" option.

Tables, forms, and other tricky structures

Tables and forms are the most common accessibility pain points.

Tables need header rows. The first row (or first column) should be explicitly marked as headers so the screen reader can announce the cell context. "January revenue $45,000" is more useful than just "$45,000".

Simple tables are more accessible than complex ones. Nested tables, merged cells, and multi-row headers often do not translate well. If possible, redesign the data as a simple rows-and-columns table.

Forms need labels. Each field — first name, date of birth, signature — should have a label that the screen reader will announce when the user tabs into the field.

Forms also need a logical tab order. Tabbing through fields should follow the visual order, not jump around the page unpredictably.

Color, contrast, and text size

Visual accessibility is about more than structure.

Contrast. Text should be dark enough against its background that someone with reduced vision can still read it. Light gray text on a white background is a classic failure. The WCAG contrast standards are a good reference; many tools can check contrast automatically.

Font size. Small fonts force readers to zoom. If the document is for screen reading, aim for body text around 11 or 12 point. Footnotes and captions can be slightly smaller, but below 8 point becomes hard for anyone.

Color alone. Do not rely on color alone to convey information. "Red items are overdue" is inaccessible to a color-blind reader. Pair the color with an icon, a shape, or text.

A practical accessibility checklist

Before you send a PDF out, run through this list.

• The source document used real heading styles, list styles, and table styles.
• Every image has alt text.
• The document converted to PDF cleanly, with tags intact.
• If the PDF contains any scanned pages, they have been OCR'd.
• Reading order follows the visual order of the page.
• Tables have header rows.
• Forms have field labels.
• Contrast and font size are reasonable.
• Color is not the only indicator of meaning.

A PDF that passes every item is vastly more usable than one that does not.

Quick wins you can do today

Full accessibility takes effort. If you do not have time for a full audit, two steps alone make a big difference:

1. Use real headings in your source document before you ever convert to PDF. That one change gives a tagged PDF to assistive tools.
2. OCR any scanned pages so the text can be read and searched. Use the OCR explainer as a reference for when and how.

Those two habits cover most of the real-world accessibility problems in everyday documents.

Put it into practice

Accessible PDFs are not a separate category of document. They are well-made documents that a wider range of people can use. Start from a structured source, add alt text, OCR any scans, and review the result. The techniques that make a PDF accessible also make it easier to search, skim, and reuse — so the work pays off for every reader, not only the ones who depend on assistive technology.

When you are ready, start with the OCR explainer for scanned content and use the Merge PDF tool and Compress PDF tool to assemble and ship the final file. Every tool runs in the browser, every upload is encrypted, and every file is deleted automatically within two hours.