Conference 14–15 October 2019 📍 Portland, Oregon, USA

PDF Days North America 2019 — PDF 2.0 Arrives in the Americas

PDF Days North America 2019 took place in Portland, Oregon on 14–15 October 2019. Coming five months after the final pre-COVID European edition, the conference brought the PDF 2.0 implementation and accessibility conversation to a North American audience, with particular focus on US Section 508 compliance, ADA litigation pressure, and the practical challenges of deploying AcroForm-based workflows at enterprise scale.

Official event page →

Key takeaways

Section 508's 2018 refresh referencing WCAG 2.0 created active enforcement pressure on federal agencies to remediate inaccessible PDFs.
PDF/UA conformance was established as the practical federal accessibility compliance target even without explicit regulatory mandate.
veraPDF and PAC provided automated PDF/UA validation mature enough for integration into document generation system workflows.
Automated validators can check structural requirements but not semantic quality — human review remains essential for real-world accessibility.
HTML web forms are generally preferable to PDF forms for new government digital services — PDF forms are appropriate for offline or legal-filing use cases.

PDF Days North America 2019 was held in Washington D.C. in October 2019, organised by the PDF Association. The conference took place as US federal agencies were grappling with Section 508 compliance and as automated PDF accessibility testing was maturing into a practical tool rather than a specialist capability. The Washington D.C. location reflected the event's strong federal government, legal, and compliance sector audience. 2019 was the year that PDF accessibility moved from "emerging requirement" to "active enforcement" in the US federal context. Section 508 of the Rehabilitation Act had been refreshed in January 2018, explicitly referencing WCAG 2.0 for digital content. Federal agencies were under scrutiny — lawsuits and compliance findings related to inaccessible government documents were being reported with increasing frequency.

Section 508 enforcement and federal PDF accessibility

Section 508 of the Rehabilitation Act (29 U.S.C. § 794d) requires federal agencies to make their electronic and information technology accessible to people with disabilities. The January 2018 "refresh" of Section 508 updated the standards to reference WCAG 2.0 Level AA for web content and electronic documents, including PDFs. The enforcement landscape in 2019: - The Access Board (the independent federal agency responsible for Section 508) was issuing updated guidance on document accessibility. - Individual agencies (DOJ, VA, HHS, SSA) faced a significant backlog of inaccessible PDF documents on their websites and in their document management systems. - Section 508 complaints about inaccessible federal PDFs were being filed with agency Civil Rights offices. - Several high-profile cases involving inaccessible federal websites and documents had resulted in settlement agreements requiring systematic remediation. The PDF/UA connection — Section 508 does not explicitly require PDF/UA conformance — it references WCAG 2.0, which does not directly specify PDF/UA. However, the PDF/UA standard (ISO 14289-1) is considered the technical implementation of WCAG 2.0's principles for PDF documents, and PDF/UA conformance is widely accepted as evidence of Section 508 compliance for PDFs. Federal agencies were beginning to use PDF/UA as their internal compliance target even without explicit regulatory mandate. Automatic document generation at scale — Many federal documents are generated automatically from databases and business systems: benefits determination letters, tax notices, court documents, regulatory filings. Retrofitting accessibility into the authoring templates for these automated systems — rather than remediating documents post-generation — was identified as the only scalable approach for agencies producing millions of documents per year.

Automated PDF accessibility testing: tools and workflows

A central theme of PDF Days North America 2019 was the maturation of automated PDF accessibility testing. By 2019, two open-source validators had become widely adopted: veraPDF — The PDF Association's flagship open-source PDF/A and PDF/UA validator. By 2019, veraPDF had mature PDF/UA-1 validation based on the Matterhorn Protocol checkpoints. veraPDF's command-line interface and Maven plugin made it suitable for integration into document management system workflows and CI/CD pipelines for automated document generation systems. verapdf.org PAC (PDF Accessibility Checker) — A Windows desktop tool from Access For All (Switzerland) that provides detailed PDF/UA validation with a clear pass/fail report and visual annotation of issues. PAC is widely used by accessibility specialists for manual review workflows. By 2019, PAC 3 was the current version. pac.pdf-accessibility.org ANDI (Accessible Name and Description Inspector) — A US Social Security Administration tool primarily for web accessibility, but with some PDF evaluation capabilities. Used internally at SSA and other federal agencies. The validation gap — Automated validators can check structural requirements (is the document tagged? does every figure have alt text? is there a document title?) but cannot assess semantic quality — whether the alt text is meaningful, whether the reading order makes sense, whether headings convey an accurate document outline. Sessions at PDF Days 2019 mapped which accessibility failures can be caught by automated testing and which require human review.

Accessible PDF forms and interactive documents

PDF forms — applications, registration documents, tax forms, benefits claims — are a significant portion of the federal PDF accessibility challenge. An accessible PDF form must meet additional requirements beyond accessible static PDFs: Form field accessibility requirements: - Every form field (text box, checkbox, radio button, dropdown) must have an accessible name (tooltip). This is provided by the /TU (user tooltip) or /T (field name) entry in the widget annotation dictionary. - The logical form tab order must match the visual layout order. Fields navigated in the wrong order by Tab key are disorienting for keyboard-only users. - Required fields must be indicated programmatically (not just visually). - Error messages and validation feedback must be programmatically associated with the relevant field. - Instructions must appear before the fields they relate to in reading order. Testing PDF form accessibility — Adobe Acrobat's built-in accessibility checker (Tools > Accessibility > Full Check) assesses basic form field requirements. PAC and veraPDF provide more detailed validation. Manual testing with a screen reader (NVDA + Adobe Reader is the standard Windows combination; VoiceOver + Preview on macOS) is essential — automated tools cannot fully replicate the screen reader experience. Web forms vs PDF forms — For new government digital services, HTML web forms (built to WCAG 2.1 AA) are generally more accessible than PDF forms, easier to validate, and work across all devices without a PDF viewer. The UK Government Design System and US Digital Services guidance both recommend HTML forms over PDF forms for new services. PDF forms remain appropriate where offline completion is required or where legal form-filing requirements specify a particular PDF form.

Frequently asked questions

What does Section 508 require for PDF documents?

Section 508 of the Rehabilitation Act (29 U.S.C. § 794d), as refreshed in 2018, requires federal agencies to make electronic and information technology accessible. For PDF documents, the applicable standard is WCAG 2.0 Level AA, incorporated by reference into the Section 508 standards (36 CFR Part 1194). The specific WCAG 2.0 requirements most relevant to PDFs include: 1.1.1 (non-text content has text alternatives), 1.3.1 (information and relationships conveyed structurally, not just visually), 1.3.2 (reading order determinable), 2.4.2 (page has a title), 3.1.1 (language identified). PDF/UA conformance (ISO 14289-1) is widely accepted as evidence of Section 508 compliance for PDFs, though it is not explicitly required by regulation. Agencies must also provide accessible PDF forms and any interactive PDF content.

How do I add alt text to images in a PDF?

In Adobe Acrobat Pro: open the Tags panel (View > Show/Hide > Navigation Panes > Tags). Find the Figure element corresponding to the image. Right-click it > Properties > set the Alternate Text field. You can also use the Reading Order tool (Tools > Accessibility > Reading Order) — right-click a figure > Edit Alternate Text. Programmatically in PyMuPDF: access the structure tree via the document's xml object (complex; structure tree manipulation is not straightforward in PyMuPDF). In iText: use PdfStructElem.put("/Alt", new PdfString("description")) on the figure element. The alt text should describe what the image conveys, not just what it depicts — for charts and graphs, the description should convey the data or trend, not just "bar chart." Decorative images (dividers, backgrounds) should be marked as artifacts (/Artifact in the structure tree) rather than given alt text.

What is the tab order in a PDF form and why does it matter for accessibility?

Tab order is the sequence in which form fields receive keyboard focus when a user presses the Tab key. For sighted keyboard users and screen reader users, the tab order determines the logical sequence for completing the form. If the tab order does not match the visual layout (e.g., Tab moves from a "First Name" field to the bottom of the form rather than to "Last Name"), the form is confusing and potentially unusable without a mouse. PDF's tab order is controlled by the /Tabs entry in each page dictionary (/S for structure order, /R for row order, /C for column order) and by the explicit order of annotation objects in the page's /Annots array. In Acrobat Pro: use the Tab Order view in the Fields panel (Tools > Prepare Form > Fields panel > Tab Order view) to visually inspect and reorder form fields. For programmatic forms built with iText or PDFBox, set the tab order explicitly when adding fields.

Try it in your browser

The PDF tools and standards discussed at this event are available free — no account needed.

Fill PDF form Edit PDF Sign PDF Open editor