Image description: Man with a gray beard wearing a white shirt and dark sweater, holding a yellow folder labeled "Accessible PDFs" with the universal accessibility symbol printed on it.
Accessible PDFs
Reading Time: 8 minutes
Accessible PDF files are digital documents designed so that people with disabilities can read, navigate, and interact with the content effectively. This means a PDF must work with assistive technologies like screen readers and magnifiers, providing a comparable experience to sighted users. In practice, an “accessible” PDF is usually a tagged PDF – one that contains semantic structure information for headings, lists, tables, images, etc. Organizations in Europe and the United States face strict requirements (and enforcement) under guidelines like WCAG 2.2 AA and PDF/UA, as well as regulations such as the European Accessibility Act (EAA) and the Americans with Disabilities Act (ADA). This blog will explain what makes a PDF accessible, why it matters, and how to achieve and maintain compliance.
What makes a PDF accessible?
The PDF should be saved as a tagged PDF, with a complete tags tree that represents the document’s structure (headings, paragraphs, lists, tables, etc.). Tags provide the semantic information that assistive technologies rely on. For example, headings are tagged so a screen reader user can jump between sections, and list or table structures are properly identified. Without tags, screen readers must infer order from layout (often incorrectly), making the PDF effectively unusable for blind users. In short, tagging is the backbone of PDF accessibility.
The content must be ordered in a logical sequence that matches the intended reading order of the document. A correct reading order ensures that screen readers narrate text in the right sequence. This includes proper nesting of headings (no skipping levels), and grouping related content in a meaningful way. Tools like Adobe Acrobat’s Reading Order panel allow verification and adjustment of this order.
All non-text elements (images, charts, graphics) should contain alternative text (alt text) descriptions, or are marked as decorative artifacts if they convey no meaningful information. Alt text provides a text equivalent for visuals so that users who cannot see the image still receive the information or context. Each meaningful image should have a concise description conveying its purpose. Decorative images are tagged as artifacts (or background) so that they are skipped by assistive tech and don’t clutter the reading experience.
If the PDF contains form fields (such as in a PDF form or application), those fields must be interactive and properly labeled. Form fields should have descriptive labels or tooltips that assistive technology can announce, allowing users to know what information to input. The tab order for form fields and links must follow a logical progression (usually matching the visual order) so that keyboard-only users can navigate the form easily. All form controls (checkboxes, text inputs, radio buttons, etc.) should be operable via keyboard and clearly indicated.
The primary language of the PDF has to be specified in the document’s properties. Setting the document language (e.g., English, French, etc.) is important so screen readers use the correct pronunciation and accent rules. Additionally, the document’s metadata should include a descriptive title (often shown in the PDF reader’s title bar) rather than an obscure file name. Other metadata, such as the author and subject, while not directly tied to accessibility for end-users, can improve the context. A missing title or language can trigger accessibility checkers to flag an error, as these are requirements in digital accessibility standards.
All text and meaningful visuals in the PDF must meet color contrast guidelines (generally 4.5:1 contrast ratio for normal text per WCAG 2.2 AA). Although color contrast is not a PDF/UA technical requirement, it is a WCAG requirement that still applies to PDF content. Authors should avoid conveying information by color alone – for example, don’t use red text to indicate something “important” without also providing a textual cue, since screen reader users or colorblind users might miss the meaning.
Hyperlinks in the PDF should use clear, descriptive text that tells the user what the link does or where it goes (instead of generic “click here” links). This is aligned with WCAG success criteria for link purpose. For instance, a link that downloads a report should say “Download Q4 Financial Report (PDF)” rather than just “Download” or an ambiguous URL.
If the PDF contains tables, they are supposed to be tagged with appropriate table structure. This means header cells are identified (with <th> tags and scope or header associations) and data cells <td> are correctly located within the table hierarchy. Simple tables should have the column/row headers marked so a screen reader can announce header information when reading cells. Complex tables (with multiple header rows or columns) may need additional mark-up (like scope or IDs) to be fully accessible.
Users must be able to select and search the text, and it should reflow when zoomed. Scanned PDFs (like a scanned document saved as PDF) are essentially images and are inaccessible unless run through OCR (Optical Character Recognition) to add actual text. An accessible PDF ensures any scanned content is OCR-processed or otherwise made readable as actual characters. This also ties into tags – OCR’d text can then be tagged appropriately.
An accessible PDF document feels like a well-structured webpage to the end user. It has a logical structure, text alternatives, and adheres to the same accessibility principles outlined in the Web Content Accessibility Guidelines (WCAG). Authors typically achieve this by creating documents in sources like Word with styles and alt text, exporting to tagged PDF, and then using a PDF editing tool to check/fix any issues.
Legal requirements and standards
PDF documents, being a common format for reports, invoices, brochures, manuals, and forms, often fall under the scope of accessibility laws if they are publicly available or used in official communications. Below we outline the key legal frameworks and standards that mandate accessible PDF files in Europe and the US.
European Accessibility Act (EAA)
The EAA covers a broad range of digital services – from e-commerce and banking to e-books and self-service kiosks. Critically, it specifies that digital content and documents provided as part of these services must be accessible. For example, “contracts and pre-contractual information” provided by banks or telecom providers must be available in accessible formats. In practice, this means PDFs for product manuals, bank statements, insurance policies, tickets, or user guides in the EU must meet accessibility criteria if they fall under the covered services.
EU regulators have tied the EAA’s web content requirements to WCAG standards. Websites and mobile apps of businesses in scope are expected to comply with WCAG 2.2 AA (or an equivalent harmonized standard such as EN 301 549). WCAG 2.2 AA includes making documents and media accessible, so PDF files published on those sites should align with those guidelines (e.g. text alternatives, structure, contrast, etc.).
Each EU member state has implemented the EAA into national law, including setting up enforcement mechanisms and penalties. The Act requires that penalties for non-compliance be “effective, proportionate and dissuasive,” which has led to significant potential fines across Europe. Regulators in EU countries can investigate complaints, require remediation of inaccessible content (including PDFs), and impose sanctions.
ADA, Section 508, and U.S. accessibility law
In the United States, accessible digital content is governed by several overlapping laws and regulations, including the Americans with Disabilities Act (ADA) and Section 508 of the Rehabilitation Act.
Under ADA Title III, disability-based discrimination by “places of public accommodation” is prohibited. The U.S. Department of Justice (DOJ) and courts have interpreted this to include websites and digital content from businesses, particularly those offering goods or services to the public. While Title III does not specify technical standards, the DOJ expects organizations to follow web accessibility guidelines. This includes ensuring that PDF documents are accessible, as they are part of the digital service.
ADA Title II applies to state and local government entities and requires public services and communications, including electronic documents, to be accessible to individuals with disabilities. In practice, many government agencies already adhere to Section 508 standards to meet ADA Title II’s requirements for effective communication. Agencies are typically allowed time to remediate older PDFs, but all new documents must be created accessibly, with some leniency for historical archives.
Section 508 of the Rehabilitation Act requires federal agencies – and, in many cases, their contractors – to ensure that electronic and information technology is accessible. Any PDF published by a federal agency, such as a report on a .gov website, must meet those accessibility standards. Section 508 explicitly references PDF/UA as a best practice, and many agencies aim for compliance with that format. Non-compliance can lead to complaints filed with an agency’s Section 508 office or escalation to the DOJ or the Office for Civil Rights. Although Section 508 does not directly apply to private sector organizations, it strongly shapes accessibility expectations across industries, and numerous states have incorporated similar accessibility standards – referencing WCAG or PDF/UA – into their own regulations.
WCAG 2.2 AA & PDF/UA standards
WCAG 2.2 (Web Content Accessibility Guidelines, version 2.2) is the latest set of internationally recognized guidelines for accessible digital content. Although developed for web content, WCAG’s principles apply to PDFs published on the web as well. In fact, many success criteria in WCAG (like text alternatives for non-text content, proper heading structure, sufficient contrast, keyboard navigability, etc.) map directly to PDF requirements. Adhering to WCAG 2.2 Level AA is often considered the goal for accessibility compliance under both the EAA and ADA, and it covers most aspects of making a PDF usable for people with disabilities.
PDF/UA (ISO 14289) is the definitive technical standard specifically for PDF accessibility. “UA” stands for Universal Accessibility. PDF/UA defines how a PDF must be structured and coded to be considered accessible. This includes rules for tagging, text alternatives, form fields, table mark-up, and more, tailored to the PDF format. Meeting PDF/UA essentially means your PDF has all the machine-testable accessibility features implemented correctly.
Importantly, PDF/UA and WCAG go hand-in-hand: PDF/UA compliance helps ensure the PDF’s content is structured in an accessible way, which in turn satisfies many WCAG criteria. Conversely, WCAG covers some broader aspects (like contrast or cognitive considerations) that PDF/UA doesn’t fully address. Thus, the best practice is to aim for dual compliance: make the PDF technically conformant to PDF/UA and functionally compliant with WCAG 2.1/2.2 AA criteria. This dual approach is actually what many laws and policies require – for example, a federal agency might say PDFs must pass Section 508 (WCAG 2.0 AA) checks and be PDF/UA conformant.
Testing and remediating PDF accessibility
Achieving compliance for PDFs requires testing each document’s accessibility and fixing any issues found – a process known as remediation. Fortunately, there are specialized tools to help with this process, as well as well-defined best practices:
- Adobe Acrobat Pro DC: Adobe Acrobat Pro is a primary tool for PDF remediation. It includes an Accessibility Checker that can perform a “Full Check” of the PDF against common accessibility rules (including many WCAG and PDF/UA checks). Acrobat’s checker will flag missing alt text, missing document title or language, reading order problems, form field issues, etc. While not infallible, it’s a great starting point. Acrobat Pro also provides tools like the Reading Order tool to visually adjust tagging and reading sequences, a Tags panel for fine-tuning the tag tree, and forms editing for adding tooltips to form fields. Using Acrobat, an author can add any missing tags, add alt text to images, define table headers, set the document title, and so on. Adobe’s “Prepare Document for Accessibility” action wizard can automate some steps (like prompting for title, running OCR on scans, etc.). After making fixes, you rerun the Acrobat accessibility check to ensure all issues are resolved. Acrobat is often the workhorse for organizations remediating a handful of PDFs manually.
- PAC (PDF Accessibility Checker) 2024: PAC 2024 is a free, dedicated PDF accessibility testing tool provided by the PDF/UA Foundation. It is a robust validator that checks all machine-testable aspects of PDF/UA as well as many WCAG criteria applicable to PDFs. PAC generates a report highlighting issues like missing tags, incorrect tag structure, missing alt text, form field errors, etc. One of its great features is a screen reader preview that simulates how the PDF’s tags will be read out loud. PAC 2024 was released as an update to PAC 2021, keeping up with newer standards. It specifically checks against WCAG 2.1 success criteria in an automated way. Since WCAG 2.2 is very similar for document-related criteria, PAC’s checks are still extremely relevant. Many accessibility professionals use PAC in tandem with Acrobat: first remediate in Acrobat, then run PAC to catch any remaining issues or to validate PDF/UA compliance. PAC’s report can also be saved as proof of compliance testing.
- Assistive technology testing: It’s essential to test PDFs manually using assistive technology. A common practice is to open the PDF with a screen reader such as NVDA (Windows) or VoiceOver (Mac), to see how well the content is announced. Listen for the logical flow: Does the screen reader announce the title, then headings in order? Are lists read as lists, tables as tables? Do images have their alt text spoken? Can you navigate form fields smoothly, hearing each field’s label? Manual testing can catch issues that automated tests might not – for example, whether the alt text actually makes sense, or if the reading order, though present, is still confusing. It also helps verify that interactive features like links and form inputs work properly with keyboard only. Many organizations incorporate assistive tech users in their testing process, or at least have their accessibility experts do a simulated review with these tools.
If you find issues, the approach to remediation can vary. Ideally, fix issues at the source – for instance, if a Word document that generates the PDF is available, it may be faster to fix styles, add alt text in Word, and regenerate the PDF with tags. This way the content authoring tool does much of the heavy lifting. If the source isn’t available or the PDF is the only working file, Acrobat Pro can be used to add missing tags and content directly. Some best practices include using templates with predefined styles for consistently structured documents, training staff who create PDFs (e.g. designers, content writers) in basic accessibility, and establishing an internal quality assurance step for important PDFs (much like you would test a new web page). For high volumes of legacy PDFs, an organization might prioritize which PDFs to fix based on usage and importance, or provide an alternate accessible format (like an HTML page equivalent) in the interim while working toward PDF remediation.
By combining automated tools and manual testing, organizations can confidently validate that their PDFs meet the required standards. It’s advisable to integrate PDF accessibility checks into your content publishing workflow. For example, when a new PDF report is created, run the Acrobat checker and PAC, fix issues, and have an accessibility specialist do a quick screen reader test before uploading it to the website. This proactive approach prevents a large accumulation of inaccessible documents.
If you are interested request an accessibility audit here.
AIOPSGROUP, a valantic company, is a leading digital accessibility consultancy helping organizations achieve full compliance with the European Accessibility Act (EAA) and the Americans with Disabilities Act (ADA). Our accessibility audits, monitoring solutions, and training programs combine automated testing with evaluations by real users with disabilities to ensure every digital platform meets WCAG 2.2 AA standards. As a trusted Accessibility compliance provider, AIOPSGROUP empowers businesses to create inclusive, legally compliant, and user-friendly digital experiences across web, mobile, and enterprise environments.
