Common PDF Accessibility Issues: A Checklist for Compliance Teams

Every PDF should declare its primary language. Screen readers use this to select voice and pronunciation. With no language set, the reader guesses, producing garbled output for non-English content. This is often blank in documents created from scanned images or older publishing workflows. What to check: Verify the language field in document properties matches the primary content language.

A PDF without a title displays its filename in the title bar and screen reader headings list. "FINAL_report_v3_EDITED.pdf" isn't useful. The title should be a human-readable description. What to check: Review document properties. If the title field is empty or contains a filename, replace it with a proper descriptive title.

Text that looks fine on screen can store incorrectly inside the PDF, especially with special characters, math symbols, or non-Latin scripts. Bad encoding causes screen readers to skip text or output nonsense. What to check: Copy text into a plain editor. If characters come through correctly, encoding is likely fine. Watch for documents that use custom or embedded fonts with non-standard encoding maps.

An untagged PDF has no structure. Screen readers fall back to the internal content stream, which often differs from the visual reading order. Tags define what each piece of content is and how it relates to the rest. What to check: Display the tag tree. If it's empty, the document needs full tagging. This is the first thing to verify on any PDF in your catalog.

Headings are the primary navigation method for screen reader users. They must follow logical order: H1, H2, H3 – without skipping. A document jumping from H1 to H3 creates confusing navigation. What to check: Review the tag tree for multiple H1s, skipped levels, or out-of-sequence headings. Also watch for documents where every heading is an H1 because the export settings were never configured properly.

Text that looks like a heading – large, bold – but is tagged as a paragraph is invisible to heading navigation. This happens frequently in documents from Word or InDesign where styles were applied inconsistently. What to check: Compare the tag tree to the visual layout. Headings appearing as <P> tags need re-mapping to <H1>–<H6>.

Meaningful content can be incorrectly artifacted – hidden from assistive technology. Conversely, decorative borders can be tagged as content, cluttering the reading experience. What to check: Ensure important content wasn't artifacted. Verify decorative elements are properly artifacted, not tagged as figures or paragraphs.

Tables need header cells (<TH>) defining what each column and row contains. Without headers, a screen reader reads data as a flat list – "$450, $320, $890" – with no context for what those values represent. What to check: Every data table should have header cells with scope attributes indicating whether they apply to rows or columns. If your document has ten tables and none have headers, that's ten separate barriers.

Tables built for visual layout often contain merged cells, empty spacer cells, or irregular structures that break under screen reader navigation. These should be restructured or replaced with simpler layouts. What to check: If meaning depends on visual relationships not expressed in tags, the table needs work.

Multi-column layouts, sidebars, and callout boxes can disrupt logical reading order. The visual layout reads left-to-right, but internal content might jump unpredictably between columns. What to check: Use a tool displaying reading order, or listen with a screen reader. Newsletters, magazines, and financial reports are frequent offenders.

Every meaningful image needs a text alternative. "Image1.png" isn't acceptable. Neither is "chart" when the image shows quarterly revenue declining 14%. What to check: Review <Figure> tags. Each meaningful image needs alt text describing what it communicates. A 200-page course catalog with 30 unlabeled charts creates 30 separate barriers.

Decorative borders and ornamental graphics should be artifacted so screen readers ignore them. When decorative elements are tagged as figures, they create noise and slow down navigation. What to check: Artifact purely decorative elements. Describe the ones carrying information.

Short alt text rarely conveys chart data. Bar charts and line graphs should be accompanied by data tables or text summaries presenting the same information in a different format. What to check: Ask whether alt text alone lets a user draw the same conclusion as a sighted reader. If not, supplement with a data table.

Diagrams, flowcharts, and infographics contain layered information one sentence can't capture. These need extended descriptions explaining relationships and flows. What to check: If the image tells a story or shows a process, brief alt text isn't enough. Add a longer description.

Every form field needs a label saying what to enter. A text box with no label is blank space – the user knows a field exists but not what belongs there. Labels must be programmatically associated, not just placed nearby visually. What to check: Tab through the form. Does each field announce its purpose? Are labels properly associated in the tag structure?

Buttons need clear, action-oriented text. "Click here" describes the mechanism, not the result. Labels should communicate what happens. What to check: Every button should make sense when read out of context.

Keyboard users navigate with the Tab key. Tab order should follow a logical sequence matching the visual layout. Broken tab order makes keyboard completion frustrating or impossible. What to check: Navigate using only Tab. If focus jumps unexpectedly, set the tab order explicitly.

Forms using JavaScript for calculations or validation need accessibility considerations – announcing errors, managing focus. Without these, assistive technology users may get no feedback when things go wrong. What to check: Test validation with a screen reader. Are errors announced? Can you recover without visual cues?

"Click the green button" or "red fields are required" fails for users who can't distinguish those colors. Color can reinforce meaning but can't be the only channel. What to check: Identify content where removing color removes meaning. Add text labels or icons to supplement color.

WCAG 2.1 AA requires 4.5:1 contrast for normal text, 3:1 for large text. Thin colored text on light backgrounds or text over images often fails. This affects users with low vision and anyone on a lower-quality screen. What to check: Test combinations with a contrast checker. Pay attention to text inside charts where contrast is often overlooked.

Documents using color to organize – coded sections, heat maps, status indicators – lose structure for color-blind users. What to check: View in grayscale or through a color blindness simulator. Does it still communicate? Add non-color cues if needed.

Group issues into three tiers: Critical – blocks access. Untagged documents, forms that can't be keyboard-operated, tables with no headers, missing document language. Fix these first. Serious – frustrating workaround. Broken heading hierarchies, missing alt text, poor reading order, insufficient contrast. Address next. Minor – detectable but manageable. Inconsistent heading levels, improperly artifacted decorative images, minor tab order issues. Batch cleanup.

The highest-leverage move is fixing the source. If PDFs come from Word templates, InDesign layouts, or a CMS, correct templates and export settings first. Every document through a fixed template comes out cleaner, preventing issues at the source rather than remediating one by one. One corrected Word template can prevent hundreds of future problems.

Not all PDFs matter equally. Prioritize public-facing over internal documents, customer forms over meeting notes, high-traffic links over archived files, and legally required content over discretionary material. An automated PDF accessibility scan surfaces issues across your catalog quickly, giving data to apply this framework objectively. Instead of guessing, you get a clear accessibility report per document – what issues exist, how severe they are, where to start. For documents passing an initial scan, remember some issues still need human judgment. Complex tables, nuanced alt text, and reading order in creative layouts benefit from expert review. Use automation to catch structural problems early, then apply manual expertise where stakes are highest.

Missing or incorrect tags. When a PDF isn't tagged, screen readers can't navigate structure, identify headings, or associate table headers with data cells. Tagging is the foundation other accessibility features depend on, and it's most often skipped during creation.

Start with problems blocking access entirely – untagged documents, missing titles, forms without labels. Then address issues seriously degrading experience: broken headings, missing alt text. Finally handle minor technical non-compliance. Consider document traffic and legal exposure when setting priorities.

Yes. A single PDF can have dozens – missing tags, no alt text, broken headings, tables without headers, contrast problems all together. A checklist helps catalog everything so you fix methodically rather than playing whack-a-mole.

Use an automated PDF accessibility scanner processing your catalog in bulk. This identifies which documents have issues and what those issues are. Results become your remediation roadmap – sort by severity and tackle highest-impact fixes first.

An automated scan checks structural aspects – tags, alt text presence, heading hierarchy, contrast, form labels. It finds rule-based issues detectable by software across hundreds of documents fast. A manual audit involves human experts reviewing with assistive technology, judging alt text quality and logical flow. Automation scales; human judgment handles nuance. The practical approach: automate the broad scan first, then apply expert review where stakes are highest.