A Practical PDF Remediation Demo: Samantha Merrett  🔗 **Source:** [A Practical PDF Remediation Demo: Samantha Merrett](https://www.youtube.com/watch?v=Eve9lbc5zDQ) > [!note]+ Document Notes > tags: ["pdf-accessibility", "document-remediation", "wcag", "screen-readers", "adobe-acrobat", "inclusive-content"] > author: "Samantha Merrett and Amber Hinds" > source: "YouTube" > reference: "https://www.youtube.com/watch?v=Eve9lbc5zDQ" > date_created: "2026-07-22" > > # 🏷️ A Practical PDF Remediation Demo: Samantha Merrett > <!-- deep-read:sections start --> ## 🧭 Table of Contents - References - Summary - Main Content and Notes - References - Paraphrase - Newsletter - Action Items - Hypotheses - Methodology - Questions - Future Research - Implications - Learning Styles Assessment - Accessibility Assessment - DEIB Assessment - Logical Validity - DARVO Analysis - Conclusion - Refactor Appendix - Template Library ## 🔗 References - [Original video](https://www.youtube.com/watch?v=Eve9lbc5zDQ) - [WCAG 2.2](https://www.w3.org/TR/WCAG22/) - [PDF/UA overview](https://pdfa.org/resource/pdfua-in-a-nutshell/) ## 📝 Summary **What happened:** Samantha Merrett demonstrates how to decide whether a PDF is necessary, prepare Adobe Acrobat, inspect and repair tags, headings, lists, tables, figures, artifacts, reading order, bookmarks, and document metadata, then test with automated tools and a screen reader. **Why it matters:** PDFs often preserve visual layout while losing the structure assistive technology needs. A repeatable repair and testing process can restore access, but remediation is costly compared with fixing the source or publishing HTML. **Stakeholders:** Disabled readers, public-sector publishers, WordPress site owners, document authors, accessibility specialists, procurement teams, legal teams, and organizations publishing policies or forms. **Risks:** An Acrobat checker can pass a document that still has a bad reading experience; edits can corrupt tags; a fixed-layout format can resist zoom and reflow; paid tooling and specialist labor can become access barriers. **Bottom line:** Ask whether the content should be a PDF first. When PDF is required, repair semantic structure and reading order, save versions often, rerun automated checks, and complete manual screen-reader testing. ## 📖 Main Content ### 1. Challenge the format The most accessible PDF may be no PDF. Check whether print fidelity or legal form preservation is necessary and whether HTML or the source document meets the user need. ### 2. Build the right workspace Acrobat Pro exposes tags, reading order, bookmarks, accessibility checks, and document properties. These tools must be visible before repair work starts. ### 3. Repair semantics, not appearance Headings, paragraphs, lists, figures, tables, links, artifacts, and language metadata tell assistive technology what the content means. Visual resemblance is not enough. ### 4. Reading order is a human judgment The editor must decide a logical sequence, then verify that the tag tree and reading-order pane match that intent. ### 5. Testing needs several layers Use Acrobat and PAC for automated signals, then inspect tags, resize and reflow, and listen with a screen reader. Save copies because Acrobat undo is limited. ## 🗒️ Notes - A successful source-document conversion is a starting point, not proof of an accessible PDF. - Artifact tags hide content from screen readers and should be used sparingly. - Bookmarks matter for long documents and are easy to miss in basic checklists. - Visual defects such as contrast and broken charts should be fixed in the source before PDF repair. - The demonstration centers Acrobat Pro; alternative tools and organizational access to licenses need separate study. ## 📚 References - The transcript is the primary record of the demonstration. - WCAG 2.2 supplies outcome criteria; PDF/UA supplies PDF-specific technical expectations. - Tool behavior should be rechecked against current Acrobat and PAC versions. ## 🗣️ Paraphrase 1. PDFs can be accessible, but conversion from Word does not finish the work. 2. Before spending hours on tags, ask whether fixed layout is truly required. 3. Set up Acrobat so tags, reading order, bookmarks, properties, and accessibility checks are available. 4. Use semantic tags to express structure and remove empty or misleading tags. 5. Add useful alternative text and mark only genuinely decorative material as artifacts. 6. Check tables, lists, headings, language, title, bookmarks, and reading order. 7. Automated checkers find some defects; manual inspection and screen-reader use find the rest. 8. Save frequently and repair visual source problems before final PDF work. ## 📰 Newsletter ### The best PDF fix may be an HTML page PDF remediation is less like pressing an accessibility button and more like rebuilding a document’s hidden skeleton. Samantha Merrett’s demo starts with the right question: does the content need fixed layout at all? If it does, the work moves through tags, reading order, figures, lists, tables, bookmarks, metadata, and testing. **WordPress angle:** WordPress publishers should prefer accessible HTML for web-first content, offer an accessible PDF only when the format serves a real need, and keep the HTML version equivalent and easy to find. ## ✅ Action Items ### DevRel - Publish a WordPress-to-PDF decision tree and a remediation lab with a broken sample document. ### OSPO - Fund open PDF checking and repair tools so accessibility does not depend on one paid desktop product. ### Community - Invite disabled document users to review the publishing checklist and compensate their expertise. ### WordPress teams - **Core:** Improve media and document metadata surfaces without claiming WordPress can certify PDF accessibility. - **Core Performance:** Measure user-visible cost before proposing a performance change. - **Core AI:** Test the claim in a disposable WordPress workflow with explicit permissions and evidence. - **Core Program Team:** Route cross-team work to named owners and a release milestone. - **Mobile:** Check the equivalent task on small screens and with mobile assistive technology. - **Playground:** Publish a disposable reproduction or teaching lab when the claim can be demonstrated safely. - **Community:** Turn the strongest lesson into a contributor discussion with affected users represented. - **Training:** Teach HTML-first publishing and a PDF remediation decision tree. - **Marketing:** State the user benefit without turning an example into proof. - **Support:** Add a diagnostic question when the source exposes a recurring support failure. - **Design:** Check focus, hierarchy, error recovery, comprehension, and alternate interaction paths. - **Documentation:** Document how to offer equivalent HTML and PDF versions with clear link purpose. - **Photos:** Use inclusive media with accurate alternative text when visuals support the lesson. - **TV:** Publish captions, a transcript, and chapter markers for any related recording. - **Polyglots:** Flag terms that need translator context and test text expansion and right-to-left layouts. - **Accessibility:** Maintain a manual PDF test guide tied to WCAG 2.2 AA and PDF/UA. - **Meta:** Check whether WordPress.org discovery, metadata, or contributor tools need a change. - **CLI:** Automate only deterministic checks; expose dry-run output and clear failure states. - **Hosting:** Translate operational claims into access controls, logs, backups, and tested recovery. - **Tide:** Add an automated check only when it is deterministic and low-noise. - **Openverse:** Use openly licensed supporting media and preserve attribution and descriptions. - **Themes:** Test the result in both classic and block themes when presentation is involved. - **Plugins:** PDF generators should preserve source semantics and disclose which checks remain manual. ### The WPOCC - Set an enterprise baseline for PDFs attached to WordPress sites, including ownership, testing, and replacement timelines. ### FAIR - Require federated documents to expose language, structure, licensing, and accessible alternate formats. ## 🧪 Hypotheses - HTML-first publication will reduce remediation hours and access defects compared with PDF-first publication. - A source-document checklist will prevent more PDF defects than post-export repair alone. - Automated checker pass rates will overestimate success in manual screen-reader tasks. - Versioned saves will reduce unrecoverable remediation failures in Acrobat. - A combined WCAG and PDF/UA checklist will produce fewer structural defects than either alone. ## 📊 Methodology - Compare matched documents published as HTML, exported PDF, and remediated PDF using disabled-user tasks. - Record repair time, defect type, tool cost, and regression rate across document teams. - Run Acrobat, PAC, keyboard, zoom, reflow, and screen-reader tests on the same corpus. - Test source-author training versus specialist-only remediation. - Predefine pass criteria and keep tool versions in the report. ## ❓ Questions - Which PDF defects create the greatest user cost? - When is fixed layout a real requirement rather than habit? - What open tools can replace parts of Acrobat Pro? - How should a WordPress site disclose the relationship between HTML and PDF versions? - Who owns retesting after the source document changes? ## 🔮 Future Research - Open-source PDF repair workflows. - Disabled-user comparisons of HTML and remediated PDF. - Regression testing after edits and reconversion. - Procurement requirements for document-authoring systems. - Reliable machine-readable reporting for PDF/UA conformance. ## 💡 Implications - **Practice:** Prefer HTML, repair source files first, save versions, and combine automated and manual testing. - **Policy:** Require an accessible alternate format, named ownership, and a dated test record for public PDFs. - **Security:** Remove hidden sensitive content and metadata during remediation without damaging accessibility. - **Education:** Teach semantics and user tasks, not only checker buttons. - **Funding:** Pay for author training, specialist review, user testing, and open tooling. ## 🧠 Learning Styles Assessment - **Visual:** The live Acrobat screens and tag-tree examples strongly support visual learners. - **Aural:** The spoken format works well; chapters and a corrected transcript improve review. - **Verbal:** Clear definitions and short summaries would help readers retain specialist terms. - **Kinesthetic:** Repairing a deliberately broken PDF alongside the demo is the best learning activity. - **Logical:** A decision table connecting inputs, risks, controls, and outcomes would strengthen the lesson. - **Social:** A guided group review can expose assumptions that one practitioner misses. - **Solitary:** A checklist and source links support independent follow-up. - **Naturalistic:** Not central to this source; system and component classification are more useful. - **Estimated reading level:** Professional reading, roughly grades 11–college, because of specialist terms. ## 📊 Accessibility Assessment - **Perceivable — WCAG 2.2 AA 1.1, 1.2, 1.3, 1.4:** The event supplies live captions and visual descriptions; the recording still needs corrected captions, a transcript, and described screenshots. - **Operable — WCAG 2.2 AA 2.1–2.5:** The player and page need full keyboard access, visible focus, large targets, and no traps. - **Understandable — WCAG 2.2 AA 3.1–3.3:** Define jargon, preserve a clear sequence, identify errors, and give recovery instructions. - **Compatible — WCAG 2.2 AA 4.1:** The lesson itself centers semantic tags, language metadata, alternate text, and screen-reader output. - **Cognitive accessibility:** Add chapters, concise takeaways, stable terms, and a low-distraction reading layout. - **Motor accessibility:** Avoid precision-only and drag-only controls; support keyboard, switch, and voice input. - **Sensory accessibility:** Do not rely on audio, color, or a visual demonstration alone to communicate meaning. ## 🌍 DEIB Assessment - **Cultural breadth:** The UK public-sector perspective is useful but needs comparison with other legal and publishing contexts. - **Inclusive language:** The teaching tone is welcoming and explains specialist terms in context. - **Neurodiversity support:** The presenter breaks the process into sections and warns against overload; a written checklist would help further. - **Representation:** A specialist presents user-centered practice, though direct testimony from PDF users would strengthen priorities. - **Psychological safety:** The session normalizes mistakes and gives editors a recovery path rather than shaming them. ## ✅ Logical Validity ### Strong reasoning - The format-decision step prevents teams from treating remediation as the only answer. - The method separates automated signals from manual user-experience checks. - The advice to fix visual defects in the source recognizes the limits of PDF repair tools. ### Fallacies and weak moves - **Automation bias — checker pass:** Treating a green checker as proof ignores reading order, link purpose, and lived use. **Fix:** Publish required manual checks beside the automated report. - **Tool centrality — Acrobat-centered workflow:** The demo can imply one paid tool is the route to accessibility. **Fix:** Compare open and platform alternatives and state tool limits. - **Overgeneralization — most accessible PDF is no PDF:** HTML is often better, but legal forms, offline use, and archival needs can justify PDF. **Fix:** Use a documented format decision rather than a blanket rule. ### Tone of voice Patient, practical, and honest about complexity, with a product and sponsor introduction that should remain separate from the evidence. ## 🛡️ DARVO Analysis - **Deny:** The talk rejects denial that PDFs can be inaccessible or that a checker is enough. - **Attack:** No attack on affected users appears. - **Reverse victim and offender:** No victim-offender reversal appears. - **Assessment:** DARVO is not present; responsibility stays with publishers and tool users. ## 🎯 Conclusion The publish-or-remediate decision is the highest-value step. If PDF remains necessary, the deliverable is not finished until structure, reading order, metadata, alternate text, bookmarks, and real assistive-technology use have been checked. ## 🧱 Refactor Appendix ### Literature Split Pad #### H1 — Question the container - **Claim:** Accessible publishing starts by deciding whether PDF is needed. - **Evidence:** The presenter uses a print, layout, legal, and alternate-format decision tree. - **Limit:** The source does not compare user outcomes across formats. #### H2 — Tags carry meaning - **Claim:** PDF accessibility depends on semantic tags and logical order. - **Evidence:** The demo covers headings, paragraphs, lists, figures, tables, artifacts, and language. - **Limit:** Correct tags can still produce a poor task experience. #### H3 — Checkers are incomplete - **Claim:** Automated tools cannot certify the full reading experience. - **Evidence:** The workflow pairs Acrobat and PAC with manual and screen-reader checks. - **Limit:** The demo does not publish inter-rater results. #### H4 — Remediation is versioned work - **Claim:** PDF repair can be fragile and hard to undo. - **Evidence:** The presenter advises frequent saves and copies. - **Limit:** The failure rate is not measured. ### Atomic Split Pad #### Z1 — Format choice is an accessibility control Choosing HTML instead of a fixed-layout file can prevent entire classes of remediation work. #### Z2 — Semantic conversion needs verification Accessible source structure may transfer into a PDF, but the exported tag tree and reading order still need inspection. #### Z3 — Automation cannot judge reading logic A checker can detect missing fields; only human review can judge whether the sequence and labels make sense. #### Z4 — Artifacting is exclusion Marking content as an artifact deliberately removes it from assistive-technology output and therefore needs a reason. ### Fleeting Queue - Create a WordPress media-library prompt for an equivalent HTML version. - Test one government PDF in Acrobat, PAC, NVDA, and browser reflow. - Map PDF/UA requirements to the current publishing checklist. <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/A Practical PDF Remediation Demo Samantha Merrett.md|A Practical PDF Remediation Demo: Samantha Merrett by youtube.com]] ## Highlights - accessible and ready to publish. I wish that was true. It would make, I'm sure, some editors' lives a lot easier. But unfortunately there's always some manual checking you need to do when you do that conversion process to make sure it works correctly. PDFs can be accessible. Hopefully, I'm gonna prove that to you today, and PDFs can work with screen readers, of course, if they are accessible. And as with all automated checkers, we cannot rely on them to give us a comprehensive compliance check when it comes to accessibility. ([View Highlight](https://read.readwise.io/read/01ky55qwxexqs4at1ajab1fcwa)) - Note: Automated checking must be paired with manual review. - Tags: accessibility, verification - that road and spend a lot of time doing it, I always just like to make sure we're doing it for the right reasons. Could we be spending that time making a Word document accessible that will still meet the same need for the users? So often with teams, I say actually the most accessible PDF is often no PDF at all. But, as with lots of things, most of the time the answer is yes, we do need a PDF. We need it tomorrow. What can we do? Within government, we tend to use Adobe Acrobat Pro to make our PDFs accessible. ([View Highlight](https://read.readwise.io/read/01ky55qvfd4qkeyd1rnrrx100x)) - Note: Prefer HTML when fixed layout is not required. - Tags: accessibility, format-choice - There are Artifact Tags. Artifact content is ignored. So marking elements of the document as Artifacts means that those elements will be completely ignored by screen readers. The purpose of doing that, is to exclude kind of like non-essential or decorative content that like doesn't contribute to the overall meaning or structure of the document. I tend to use that very sparingly because I don't really think much of ([View Highlight](https://read.readwise.io/read/01ky55qyr7sdx8dd3ssdtkpphw)) - Note: Artifacting removes content from screen-reader output. - Tags: semantics, screen-readers - Acrobat is prone to crashing, as I'm sure lots of other softwares are, so just save your work frequently. There's also a dog on this slide with a headset and microphone looking like they're working from home, which is quite funny. Acrobat's undo function is quite limited, so save a copy of your work quite frequently. Sometimes when you're deep into kind of remediation, you're moving things around, yeah, you can't undo things that easily, so just make sure you save. And if your document has any kind of like visual accessibility errors, by ([View Highlight](https://read.readwise.io/read/01ky55r2hyzcwhermzexvbgqwy)) - Note: Remediation needs frequent recoverable saves. - Tags: workflow, risk-management - that I mean like color contrast problems or like graphs and images that have not been pulled through correctly, you can't amend those in Acrobat, so go back and get the right in the original before you start any PDF work. Take it from someone who's had to do lots of things again because they've not saved or she can't undo what she's done. Final things for you, if you don't take anything else away from today, check your Reading Order Pane, rerun the Accessibility Checker, and check everything with a screen reader if you can, 'cause of course ([View Highlight](https://read.readwise.io/read/01ky55r0f16pjg77jgm48ghcfw)) - Note: Final checks include reading order, automation, and assistive technology. - Tags: verification, reading-order ## Links - [[3. Resources/Permanent Notes/Accessibility Enforced at Authoring Time Beats Post-Hoc Auditing]] — supports: accessible source documents cost less than downstream PDF repair. - [[3. Resources/Permanent Notes/Visual Layout Must Preserve Sequential Meaning and Focus Order]] — applies-in: PDF tags and reading order must agree with the visual document.