PDF Accessibility: Tagging, Forms, OCR & Legal Requirements

PDFs are lawsuit magnets. They're frequently inaccessible, often contain forms that don't work with assistive technology, and are frequently overlooked in accessibility audits. If your website uses PDFs—and most do—you're likely facing significant ADA compliance risk. This guide covers everything you need to know about making PDFs accessible: tagging, form fields, text extraction, OCR, searchable PDFs, and legal requirements.

PDFs are designed for print, not digital accessibility. They lack semantic structure, often lack proper text encoding, and can be nearly impossible for screen reader users to navigate. Forms embedded in PDFs frequently don't work with accessibility features. The result: PDFs are common defendants in accessibility lawsuits. PDFs on websites must comply with WCAG 2.1. This applies whether PDFs are embedded in HTML or linked from pages. If a PDF is essential to accessing website content, it must be accessible. Courts have consistently held that inaccessible PDFs violate the ADA Title III. Blind users relying on screen readers can't access untagged PDFs. Users with motor disabilities can't navigate or fill forms. Low-vision users may struggle with poor contrast. Deaf users can't access audio content in PDFs. Making PDFs accessible benefits all users.

PDF tags are invisible structural markers that tell assistive technology what each element is: heading, paragraph, list, table, form field, etc. Tagged PDFs have a logical reading order that screen readers can follow. Untagged PDFs require screen readers to guess structure, resulting in confusion and inaccessibility. In Adobe Acrobat Pro, use Tools > Accessibility > Add Tags to Document. This auto-tags the PDF based on visual structure. Review the tags—auto-tagging isn't perfect. Fix incorrect tags, add missing ones, and establish a logical reading order. This is time-consuming but essential. The easiest approach: create content in an accessible format (Word, HTML, InDesign) with proper structure, then export to PDF with tags preserved. Use proper heading styles, list formatting, and table structure in the source. When you export, tags convert automatically. This is far easier than tagging a PDF after creation. Test with screen readers (NVDA, JAWS, VoiceOver). Verify reading order makes sense. Check that all content is accessible. Run axe PDF or Acrobat's accessibility checker. Fix any issues before deploying.

Many PDFs contain forms with fields that don't work with screen readers or keyboard navigation. Users can't identify form fields, can't fill them out, and can't submit. These PDFs are completely inaccessible to disabled users. Every form field needs a label. In Adobe Acrobat Pro, right-click the field, select Properties, and add a tooltip (this becomes the field label). Ensure label text is descriptive: "Email address" not "Field 1". Add required field indicators. Include instructions for complex fields. Use appropriate field types: text boxes for text input, radio buttons for single selection, checkboxes for multiple selections, dropdown lists for long lists. Each type should work with assistive technology. Test all field types with screen readers. Users must be able to Tab through form fields in logical order. Set tab order in Acrobat: Tools > Accessibility > Set Document Tab Order. The tab order should match visual order on the page. Test keyboard-only navigation. If a form field has an error, clearly communicate it. Associate error messages with fields so screen readers announce them. Provide suggestions for fixing errors. Avoid using color alone to indicate errors. Better than PDF forms: convert forms to HTML. HTML forms are much more accessible and provide better user experience. If you must use PDF forms, make them accessible as described above. But when possible, use web forms instead.

Some PDFs contain selectable text (copy-able). Others are image-based (scanned documents). Screen readers can access selectable text but can't read image-based PDFs. If you have image-based PDFs, you must use OCR (Optical Character Recognition) to convert images to text. OCR analyzes scanned document images and converts them to machine-readable text. Adobe Acrobat Pro has built-in OCR: Tools > Accessibility > Recognize Text. Alternatively, use online OCR services. OCR is typically 95-98% accurate—review the results. OCR sometimes misreads text, especially poor-quality scans. After running OCR, manually verify important content. Check financial data, contact information, and dates. Fix any OCR errors before deploying the PDF. After OCR, the PDF needs proper tagging. Use Adobe's auto-tag feature to tag the OCR output. Review and fix tags. The document should now be accessible to screen readers.

Users should be able to search PDFs using Ctrl+F to find text. Scanned image-based PDFs aren't searchable. After OCR, PDFs become searchable. This benefits all users, not just disabled users. Ensure searchable text is embedded in the PDF. In Adobe, File > Properties > Content tab shows if the PDF is searchable. If not, run OCR as described above. If your website has a search function, ensure PDFs are indexed and searchable through the site search. This requires proper PDF configuration and search index settings. Test that PDF results appear in site search.

Tables in PDFs must have proper structure: header rows identified, data cells associated with headers. Screen readers announce relationships between cells. Without proper structure, tables are unintelligible. Tag table headers as TH tags, not regular cells. Every image in a PDF needs alt text describing it. In Adobe Acrobat, right-click image > Edit Tag > Touch Up Properties, add alt text. Decorative images should be marked as decorative so screen readers skip them. Informative images need descriptive alt text. Multi-column layouts, text wrapping around images, and complex designs confuse screen readers. Structure PDFs logically. When possible, simplify layout. Ensure reading order makes sense when following the tagged content.

Industry standard for PDF accessibility. Features include auto-tagging, form field creation, OCR, and accessibility checker. Expensive but comprehensive. Desktop-only. Free accessibility checker for PDFs. Scans for WCAG violations. Provides remediation suggestions. Browser-based and desktop tools available. Built into Acrobat Pro. Scans for accessibility issues and suggests fixes. Not perfect but helpful starting point. LibreOffice, Microsoft Word, and InDesign all support creating accessible PDFs. When exporting to PDF, ensure options preserve document structure and create tagged PDFs.

HTML is inherently more accessible than PDF. HTML works on all devices, supports responsive design, and is much easier to make accessible. PDFs are static, fixed-format documents designed for print. Reports, forms, documents—all can be converted to HTML. Instead of downloading a PDF invoice, view an HTML page. Instead of PDF forms, use web forms. HTML provides better accessibility and better user experience. Sometimes PDF is the right choice: printable documents users want to save locally, documents that require specific layout preservation, archival documents that should remain in original format. In these cases, make the PDF accessible. Best practice: provide content as accessible HTML with a downloadable PDF option. The HTML version is primary (fully accessible). The PDF is an alternative (for printing or offline use). Both should be accessible.

Proper tagging (Tags panel in Acrobat shows tags). Logical reading order. Accessible form fields (if forms present). Alt text for images. Proper table structure. No missing content. Screen readers (NVDA, JAWS, VoiceOver). Keyboard-only navigation. Zoom at 200%. Color-blind mode. Run axe PDF or Acrobat accessibility checker. Fix all identified issues. Create accessible PDFs from source (Word, HTML) rather than tagging after creation.