# A Practical PDF Remediation Demo: Samantha Merrett > [!question] Lingering Questions > - The demo doesn't compare user task-completion outcomes across formats — is there data on how much better HTML actually performs versus a well-remediated PDF for the same content? > - What's the actual failure rate of PDF remediation edits corrupting tags, and how does that compare with the cost of publishing HTML from the start? > [!tip] Article Ideas > - "The most accessible PDF is no PDF" as a procurement-decision framework: a format-choice checklist that front-loads the question before any remediation work starts. > [!link] Cross Reference > - [[3. Resources/Permanent Notes/Native HTML Semantics Beat Re-Implemented ARIA]] — the format-choice argument here (choose HTML over PDF) is the document-level version of that markup-level claim > [!quote] Vocabulary > - *Artifacting* — in PDF remediation, marking content as decorative so assistive technology skips it; deliberate exclusion that needs a reason. > - *PDF/UA* — the ISO standard for accessible PDF structure, distinct from and narrower than full WCAG conformance. ## Metadata - Source: [[3. Resources/Readwise/Articles/A Practical PDF Remediation Demo Samantha Merrett]] - Format: recorded demo/workshop video; Samantha Merrett walks through Adobe Acrobat remediation with Amber Hinds. ## Author's thesis The most accessible PDF may be no PDF — the format choice itself is an accessibility decision. When PDF is genuinely required, accessibility depends on repairing semantic structure (tags, headings, lists, tables, reading order) and verifying it with both automated checkers and manual screen-reader testing, since automated tools alone cannot certify the reading experience. ## Key arguments (≤3) 1. **Format choice is itself a control.** Before any remediation work, ask whether the content needs to be a PDF at all — print fidelity or legal form preservation are the real reasons to keep it one; most publishing isn't. 2. **Tags carry the meaning, and correct tags aren't sufficient.** The demo covers headings, lists, tables, figures, artifacts, and reading order — but correct tags can still produce a confusing task experience if the logical sequence is wrong. 3. **Automated checkers are necessary but incomplete.** Acrobat's and PAC's automated checks catch structural problems; only a human, ideally with a screen reader, can judge whether the sequence and labels actually make sense. ## Claim atoms ### Question the container Claim: Accessible publishing starts by deciding whether PDF is needed at all. Evidence: the presenter uses a decision tree weighing print fidelity, layout, legal-form requirements, and alternate formats before starting remediation. Limit: the source doesn't compare user outcomes across formats empirically. ### Tags carry meaning Claim: PDF accessibility depends on semantic tags and logical reading order. Evidence: the demo walks through headings, paragraphs, lists, figures, tables, artifacts, and language settings. Limit: correct tags can still produce a poor task experience — structure isn't the whole story. ### Checkers are incomplete Claim: Automated tools cannot certify the full reading experience. Evidence: the workflow pairs Acrobat's and PAC's automated checks with manual and screen-reader testing. Limit: no inter-rater reliability data is published for the manual pass. ### Remediation is versioned, fragile work Claim: PDF repair can corrupt tags and is hard to undo. Evidence: the presenter advises frequent saves and copies during remediation. Limit: no measured failure rate is given. ## Permanent candidates - **Format choice is an accessibility control exercised before remediation starts** — supported by the "question the container" atom; the single most generalizable claim in a thin source. → promoted. ## Processing checklist - [ ] Test one real government or nonprofit PDF through Acrobat, PAC, and NVDA/browser reflow to compare against the demo's workflow - [ ] Map PDF/UA requirements against the current publishing checklist for any docs I remediate - [x] Connect into the relevant MOC — none from the fixed MOC list fits closely enough to force ## Links - (no strong MOC fit in the current list — this is a narrow technical-remediation topic without a matching MOC) - [[3. Resources/MOCs/Accessibility & Disability Inclusion MOC]] — applies-in: Joins the cluster on accessible document practice.