PDF/UA (ISO 14289) defines the accessibility requirements for PDF documents. The Summit's practical focus examined the gap between what the specification requires and what organisations actually deliver. The Matterhorn Protocol — published by the PDF Association alongside PDF/UA — defines 136 checkpoints that characterise PDF/UA conformance, dividing them into: - Machine-verifiable checkpoints (can be checked by automated tools like PAC or veraPDF) - Human-verifiable checkpoints (require human judgement — e.g., whether alt text accurately describes an image, whether reading order is logical) Summit sessions revealed consistent failure patterns across organisations: 1. **Missing or incorrect heading structure** — The most common failure. Documents exported as flat PDFs with no heading tags, or with headings applied visually (bold text at large size) but not tagged as H1/H2/H3 in the PDF structure tree. 2. **Incorrect reading order in multi-column layouts** — PDF generation tools often produce PDFs where the text extraction order follows document page order rather than the intended reading order, causing screen readers to read text from the wrong column. 3. **Decorative images without /Artifact marking** — Images that are purely decorative (borders, backgrounds) should be marked as /Artifact so screen readers skip them. Unmarked decorative images generate spurious alt text announcements. 4. **Tables without header cells** — Data tables require /TH header cells with /Scope attributes; presentational tables require /Role set to /Presentation.

The Summit covered the two main approaches to producing accessible PDFs: Fix at source — Correct the accessibility problems in the source document (Word, PowerPoint, InDesign) and re-export. This is the most scalable approach for regularly produced documents. Microsoft Word's Accessibility Checker (built into the Review tab) identifies most heading, alt text, and table header issues before export. Adobe InDesign has a dedicated Export to Tagged PDF workflow with accessibility options. Remediate the PDF directly — When source documents are unavailable (scanned archives, third-party documents), use Adobe Acrobat Pro's Accessibility tools or specialist tools like CommonLook PDF to add and correct the tag tree directly. This is labour-intensive but necessary for legacy document backlogs. For organisations with large backlogs, the Summit recommended a tiered approach: 1. Categorise documents by usage frequency and user impact 2. Apply automated fixes where possible (PAC or veraPDF in batch mode to identify and flag failures) 3. Prioritise high-impact, high-frequency documents for manual remediation 4. Create accessible templates and authoring guidance to prevent new accessibility failures in future production Adobe Acrobat's accessibility features provide the most complete remediation toolset, but licensing costs motivate many organisations to explore open-source alternatives for validation (veraPDF) and bulk processing.

A critical track at the Summit addressed the gap between automated tool validation and actual user experience. A PDF can pass all 136 Matterhorn Protocol checkpoints and still be difficult to use with specific screen readers — because different AT (assistive technology) software interprets PDF structure differently. Primary testing combinations for US and EU markets: - **NVDA + Chrome** — Most common free screen reader setup; widely used by screen reader users - **JAWS + Edge/Chrome** — Most common enterprise and workplace screen reader - **VoiceOver + Safari (macOS/iOS)** — Default Apple screen reader - **TalkBack (Android)** — Default Android screen reader, used with Chrome Summit sessions demonstrated that the same PDF can behave differently across these combinations — particularly for: - Complex table navigation - Form field announcement and focus management - Figure/caption association - Document navigation via headings (using the AT's heading navigation shortcut) The recommended practice is to validate with PAC/veraPDF first (catch all machine-verifiable failures), then conduct manual testing with at least two screen reader / browser combinations (NVDA+Chrome and JAWS+Edge are the recommended minimum for US/EU markets). The WebAIM Screen Reader User Survey provides current data on screen reader market share to inform testing prioritisation.