The Art of Accessibility Making Documents Delightfully Inclusive

The Art of Accessibility: Making Documents Delightfully Inclusive ![rw-book-cover](https://img.youtube.com/vi/-2i6LX7L9HY/maxresdefault.jpg) 🔗 **Source:** [The Art of Accessibility: Making Documents Delightfully Inclusive](https://www.youtube.com/watch?v=-2i6LX7L9HY) > [!note]+ Document Notes > tags: [document-accessibility, wcag, screen-readers, pdf-accessibility, microsoft-word] > author: Samantha Merrett > source: WordPress Accessibility Day 2025 > reference: https://www.youtube.com/watch?v=-2i6LX7L9HY > date created: 2026-09-08 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: The Art of Accessibility: Making Documents Delightfully Inclusive >  ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) - [🔄 Refactor Appendix](#-refactor-appendix--the-art-of-accessibility-making-documents-delightfully-inclusive) ### 🔗 References - [WordPress Accessibility Day 2025](https://2025.wpaccessibilityday.org/) — hosting event, feedback form at 2025.WPAccessibilityDay/feedback (t=2936s) - Deque Systems — Jeremy Rivera's employer, session host (t=96s) - UK Ministry of Justice, Digital Accessibility Team — Samantha Merrett's employer (t=272s–288s) - International Association of Accessibility Professionals (IAAP) — certifying body for Merrett's Certified Professional in Accessibility Core Competencies (CPACC) and Accessible Documents Specialist (ADS) credentials (t=120s–128s) - Web Content Accessibility Guidelines (WCAG) 3.0 (in progress) — referenced re: "access for as many people as possible" (t=524s–540s) - PAC (PDF Accessibility Checker) — free PDF/UA compliance tool (t=2373s–2382s) - PAVE — free PDF remediation tool, ~5MB file-size ceiling (t=2417s–2423s) - CommonLook PDF, Axes 4, Equidox — paid PDF remediation tools named without endorsement (t=2431s–2436s) ## 📝 Summary - **What happened.** At WordPress Accessibility Day 2025, Samantha Merrett — senior accessibility specialist at the UK Ministry of Justice's Digital Accessibility Team — gave a 40-minute session on making Word documents, PowerPoint presentations, and Excel spreadsheets accessible, followed by an 11-minute audience Q&A moderated by Jeremy Rivera (Deque Systems). - **Why it matters.** Documents remain a major, under-addressed accessibility surface next to websites: the talk treats format choice (Word vs. PDF vs. PowerPoint vs. Excel vs. plain HTML) as the first accessibility decision, made before a single sentence is written, because a fully accessible Word document exported to PDF can become inaccessible in the conversion (t=421s–432s). - **Key stakeholders.** Document authors and editors in any organization producing internal or public-facing files; screen reader and voice-recognition software users; UK public-sector bodies bound by accessibility law; WordPress community event organizers who produce their own slide decks and handouts. - **Risks and tradeoffs.** PDF is singled out as the default worst choice for accessibility unless the source software's export path is verified (t=852s–954s); automated accessibility checkers (PowerPoint's built-in checker, Acrobat) catch obvious problems like stark color-contrast failures but miss near-threshold contrast and generic link text, so manual review stays necessary (t=2760s–2812s). - **Bottom line.** Choose the simplest compatible format (usually Word), structure it with real headings and real tables from the start, write context-specific alt text instead of relying on software automation, and test throughout creation rather than only at the end (t=2237s–2290s). ## 📖 Main Content Merrett frames document accessibility as primarily a sequencing problem, not a features problem: pick the right format before creating content, because format conversion is where accessible work gets destroyed (t=421s–432s). She defines an accessible document as one that "allows as many people as possible to access that information" (t=467s–470s) and ranks her motivations for doing the work — in order — as: it gives everyone equal access to information (top of her list, t=512s–519s), it may become part of WCAG 3.0's stated purpose (still "rumored," in progress, t=524s–540s), and it's UK legal compliance for her public-sector role (bottom of her list — she doesn't want compliance to be the primary motivator, t=553s–566s). To choose a format, she uses three questions: who will use the document, how will they use it, and how will it be shared (t=600s–610s). A spreadsheet fits budget calculations shared by email; a presentation fits information shown live on a screen (t=613s–646s). PowerPoint, she argues, is "one of the most misused format types" (t=668s) — it should hold visual, story-driven presentations only, not the long reports it's often stretched to contain, because those belong in Word (t=683s–709s). Excel should hold data for storage, analysis, and reporting, not prose, project plans, or forms (t=719s–737s). Documents (she uses Word as her working example) get the broadest recommendation: "if it's made in Word, it can stay in Word" (t=755s–769s), because Word files are more flexible, convert cleanly to PDF when needed, and are more compatible with assistive technology than most alternatives (t=780s–804s). PDFs get the harshest treatment. Asked whether to create one, her answer is "pretty much most of the time...no" (t=860s–863s). She cites an assistive-technology user's testimonial: "I always open a PDF with trepidation because more than half the time, trying to read one with my assistive technology is a frustrating experience" (t=881s–890s). PDFs weren't designed to be flexible, and UK government produced a heavy "churn" of them in the past despite the format's rigidity (t=930s–943s). The Word-document tips section covers: headings as "the backbone of any document" that must use real style-based structure, not bold-and-large-font imitation (t=1008s–1032s); one Heading 1 per document, with the Title style avoided in favor of Heading 1 as the top level (t=1105s–1121s); tables that are never pasted in as screenshots, always have a header row, never split rows across pages, never merge or split cells, and get a title plus optional alt text for complex data (t=1164s–1264s); headers/footers that are not automatically read by screen readers under recent testing, so version numbers and dates placed there may be inaccessible — only page numbers are safe because they're shown elsewhere too (t=1329s–1353s); spacing built with page breaks, tabs, and line-spacing settings rather than repeated Enter presses, which screen readers announce as "blank, blank, blank" (t=1372s–1432s); alt text that is context-dependent and personal to the image's purpose, not generic or software-automated without a human check (t=1452s–1591s), demonstrated with a live example contrasting "Image 342.jpg" (bad), "Dog with its mouth wide open" (literal but okay), and a fuller emotionally descriptive version (good) (t=1538s–1591s); descriptive link text instead of "click here" or bare URLs, because screen reader users often navigate via a links list (t=1608s–1630s); and neurodiversity-friendly formatting — plain English, minimal bold/italic/underline, checked color contrast (t=1633s–1659s). For presentations: use the master/slide-master layout for consistent, accessible color and logo use (t=1679s–1704s); use sections to structure long decks (t=1710s–1726s); give every slide a unique, descriptive title, since screen reader users rely on titles to track position, and duplicate-content slides need a "Continued" marker (t=1748s–1786s); use readable fonts, generous spacing, no transitions, short descriptive links, and unique titles (t=1813s–1831s); and never indicate meaning with color alone — describe items by label plus color ("Labelled with letter A and colored red"), and send slides in advance with notes for attendees not viewing the screen (t=1856s–1892s). For spreadsheets: add an index sheet with a hyperlinked contents list when a workbook has multiple sheets (t=1919s–1939s); use Cell A1 deliberately, either for a workbook summary or a table title depending on context (t=1942s–1983s); rename sheets and tables from defaults like "Sheet1" to meaningful names (t=1990s–2017s); never merge or split cells, since screen reader users count cells to track location (t=2048s–2069s); and never leave data cells blank — use "N/A," a dash, or zero, and delete genuinely empty rows/columns so users don't mistake them for the end of the data (t=2072s–2118s). Closing best practices: test at every stage of creation rather than only at the end (t=2233s–2253s); never produce a separate "accessible version" alongside an inaccessible original — make one document that works for everyone (t=2212s–2228s); and build accessibility in from the start, even if you're not the document owner, by influencing others early (t=2261s–2290s). In Q&A, Merrett clarifies: Adobe Acrobat isn't the only PDF remediation tool — PAC (free, full PDF/UA compliance) and PAVE (free, ~5MB limit) exist alongside paid tools like CommonLook PDF, Axes 4, and Equidox, though she cautions against tools marketed as fully automated remediation (t=2338s–2436s); decorative-image marking should be rare, since most images serve a purpose and deserve real alt text (t=2453s–2512s); underline should be reserved for links only, exactly as she'd taught (t=2526s–2554s); the single most common mistake is missing heading structure, and the single highest-impact beginner fix is adding real headings plus alt text (t=2570s–2659s); PowerPoint-to-PDF exports and Google Slides-to-PDF exports are both poorly suited to accessibility because the formats were never meant to be compatible (t=2673s–2725s); accessibility checkers are a valuable starting point but miss near-threshold contrast and bare URLs, so manual checks stay necessary (t=2739s–2816s); and PDF compression can strip tags, reading order, alt text, form fields, embedded fonts, and metadata depending on the compression method, so always re-check accessibility after compressing (t=2824s–2886s). ### 🗒️ Notes #### ⏱️ [00:01:33](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=93s) Introduction: Jeremy Rivera introduces Samantha Merrett - Jeremy Rivera, developer advocate at Deque Systems, hosts WordPress Accessibility Day 2025 and introduces Merrett. - Merrett is credited as a senior accessibility specialist at the UK Ministry of Justice, IAAP CPACC- and ADS-certified, with a career across UK government departments. #### ⏱️ [00:04:29](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=269s) Who Samantha is - Self-introduction: pronouns she/her, self-describes appearance for attendees using screen readers ("blonde hair...in a ponytail today...wearing a pair of glasses," t=294s–300s). - Shares four personal-life pictures she audio-describes live: her dog Bella, travel items, her fiancé Liam at Disneyland, and yoga — modeling the alt-text practice she later teaches. #### ⏱️ [00:06:37](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=397s) Why format choice comes first - States the session's premise: format has "a really big impact on the final accessible output" because an accessible document can be exported/converted into something inaccessible (t=418s–432s). #### ⏱️ [00:07:18](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=438s) Defining an accessible document - > [!quote] "An accessible document allows as many people as possible to access that information." #### ⏱️ [00:08:29](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=509s) Why it matters: equal access, WCAG 3.0, and law - Ranks her own motivations: equal access to information first (t=512s), WCAG 3.0 potentially formalizing it (t=524s–540s, still "rumored," in progress), UK legal requirement last (t=543s–566s) — she explicitly doesn't want compliance to be the primary driver. #### ⏱️ [00:09:31](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=571s) Three questions for choosing a format - Who's going to use the document, how are they going to use it, how are you going to share it (t=600s–605s). #### ⏱️ [00:10:51](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=651s) PowerPoint: use and misuse - > [!quote] "PowerPoint is one of the most misused format types." - Should hold visual, story-driven presentations only, not reports (t=676s–709s). #### ⏱️ [00:11:54](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=714s) Excel: intended use - Store, analyze, and report on large data sets; not for prose, project management, or forms (t=719s–737s). #### ⏱️ [00:12:23](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=743s) Word: "if it's made in Word, it can stay in Word" - Word recommended as the default safe choice — more flexible, converts cleanly, more compatible with assistive technology (t=755s–804s). #### ⏱️ [00:14:07](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=847s) PDFs: "should I create a PDF? No" - > [!quote] "My answer pretty much most of the time is no." - Assistive-technology user testimonial: reading a PDF is "a frustrating experience" more than half the time (t=881s–890s). #### ⏱️ [00:15:10](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=910s) Why PDFs are problematic - Not designed to be flexible; UK government produced a "churn" of PDFs historically despite the format's rigidity (t=926s–943s). #### ⏱️ [00:16:40](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=1000s) Headings: the backbone of a document - > [!quote] "Headings are the backbone of any document." - Bold, size-28 text is not a heading; must use real style-based headings, one Heading 1 per document, Title style avoided (t=1076s–1121s). #### ⏱️ [00:18:46](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=1132s) Accessible tables - Never paste a table as an image (t=1164s–1178s); always add a header row, never split rows across pages, never merge/split cells, add a title and optional alt text, verify tab order (t=1194s–1275s). #### ⏱️ [00:21:47](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=1307s) Headers and footers are not automatically read - Screen readers under recent testing don't automatically read page headers/footers; version numbers and dates placed there may be inaccessible, while page numbers are safe because shown elsewhere (t=1326s–1353s). #### ⏱️ [00:23:58](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=1358s) Adding spacing correctly - Use page breaks and line-spacing settings instead of repeated Enter presses; screen readers announce excess Enter presses as "blank, blank, blank" (t=1369s–1432s). #### ⏱️ [00:24:00](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=1440s) Images and alt text - > [!quote] "Alt text is very context-dependent" - Live example: "Image 342.jpg" (bad) vs. "Dog with its mouth wide open" (okay) vs. a fuller emotional description (good) (t=1538s–1591s). Warns that software automation for alt text is "not necessarily great at getting it right" and should always be double-checked (t=1478s–1487s). #### ⏱️ [00:26:36](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=1596s) Formatting link text - "Click here" and bare URLs are unhelpful because screen reader users navigate via a links list; link text must be descriptive (t=1608s–1630s). #### ⏱️ [00:27:10](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=1633s) Neurodiversity in Word documents - Plain English, minimal bold/italic/underline, checked color contrast (t=1648s–1659s). #### ⏱️ [00:27:56](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=1676s) Polished presentations: master slide and structure - Use the slide master for consistent accessible color/logo layout; use sections to structure long decks (t=1679s–1726s). #### ⏱️ [00:29:04](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=1744s) Unique slide titles - Every slide needs a unique descriptive title; screen reader users rely on titles to track position; duplicate-content slides get a "Continued" marker (t=1748s–1786s). #### ⏱️ [00:30:51](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=1851s) Don't indicate meaning with color alone - Describe items by label plus color ("Labelled with letter A and colored red," t=1881s–1885s); send slides in advance with notes for attendees not viewing the screen (t=1889s–1892s). #### ⏱️ [00:31:50](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=1910s) Excel: index sheets - Multi-sheet workbooks need an index sheet with a hyperlinked contents list (t=1917s–1939s). #### ⏱️ [00:32:22](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=1942s) Excel: Cell A1 - Use deliberately for a workbook summary (first sheet) or a table title (any sheet) depending on context (t=1954s–1983s). #### ⏱️ [00:34:05](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=2045s) Excel: no blanking, no merging - Never merge/split cells — screen reader users count cells to track location; replace blank cells with "N/A," a dash, or zero; delete truly empty rows/columns (t=2048s–2118s). #### ⏱️ [00:36:08](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=2168s) Final best practices - Never maintain two versions of a document (t=2212s–2228s); test at every stage of creation, not just the end (t=2233s–2253s); build accessibility in from the start (t=2261s–2290s). #### ⏱️ [00:38:30](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=2310s) Q&A: is Adobe Acrobat the only PDF tool? - No — PAC (free, full PDF/UA compliance) and PAVE (free, ~5MB limit) exist; paid tools include CommonLook PDF, Axes 4, Equidox; caution against tools advertised as fully automated remediation (t=2338s–2436s). #### ⏱️ [00:40:45](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=2445s) Q&A: decorative images - Mark-as-decorative should be rare; most images have a purpose and deserve real alt text; remove an image entirely if it truly adds nothing (t=2453s–2512s). #### ⏱️ [00:41:56](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=2516s) Q&A: underline is for links only - Confirms links should always be underlined; other text should not be, so users can visually identify links (t=2526s–2554s). #### ⏱️ [00:42:40](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=2560s) Q&A: most common mistake and best beginner fix - Most common mistake: missing or fake (bold/large-font) heading structure (t=2583s–2609s). Best beginner-impact fixes: real headings plus alt text (t=2647s–2659s). #### ⏱️ [00:44:24](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=2664s) Q&A: PowerPoint-to-PDF and Google Sheets accessibility - PowerPoint-to-PDF exports are "not very accessible" because the formats "were never meant to be compatible"; Google's presentation-to-PDF export is no better (t=2678s–2725s). #### ⏱️ [00:45:29](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=2735s) Q&A: is the PowerPoint accessibility checker helpful? - Yes, as a starting point — but it misses near-threshold color contrast and bare-URL link text, so manual checks are still required (t=2744s–2816s). #### ⏱️ [00:47:01](https://www.youtube.com/watch?v=-2i6LX7L9HY&t=2821s) Q&A: does compressing a PDF affect accessibility? - Depends on method — compression can flatten text/structure into images, stripping tags, reading order, alt text, form fields, embedded fonts, and metadata; always re-check accessibility after compressing (t=2829s–2886s). ## 📚 References - [WordPress Accessibility Day 2025](https://2025.wpaccessibilityday.org/) — event site, feedback at /feedback (t=2936s) - [Deque Systems](https://www.deque.com/) — Jeremy Rivera's employer and session host - International Association of Accessibility Professionals (IAAP) — CPACC and ADS certifications referenced (t=120s–128s) - Web Content Accessibility Guidelines (WCAG) — versions 2.2 (current, used for the assessment sections below) and 3.0 (in progress, referenced at t=524s) - PAC — pac.pdf-accessibility.org (free PDF/UA checker, referenced t=2373s) - PAVE — pave-pdf.org (free PDF remediation tool, referenced t=2417s) ## 🗣️ Paraphrase Merrett opens by treating document accessibility as a sequencing problem rather than a checklist: pick the right format before you write a word, because converting an accessible file into the wrong format can erase the accessibility work already done. She defines an accessible document simply — one that lets as many people as possible get at the information — and ranks her own reasons for caring about it deliberately, putting equal access above the possibility that WCAG 3.0 formalizes the idea, and putting UK legal compliance last on purpose, because she doesn't want obligation to be the reason people do the work. The bulk of the talk is a practical audit checklist delivered format by format. Word gets the default recommendation for almost everything because it's flexible and assistive-technology-friendly; PowerPoint is reserved for visual, story-driven presentations, not reports; Excel is for data, not prose or forms; and PDF is discouraged nearly across the board, backed by a direct testimonial from an assistive-technology user who finds most PDFs frustrating to read. Within each format she walks through concrete mechanics — real style-based headings instead of bold pseudo-headings, tables built with header rows and never pasted in as screenshots, headers/footers that screen readers skip by default, spacing built with page breaks rather than repeated Enter presses, alt text that's specific to context rather than generic or auto-generated without review, descriptive link text instead of "click here," unique slide titles, and color never used as the sole signal of meaning. She closes with three habits: never keep two versions of a document, test throughout creation instead of only at the end, and build accessibility in from the first draft. The Q&A extends this into tooling and edge cases — PDF remediation tools beyond Acrobat, when to actually mark an image decorative, and how compression can quietly strip a PDF's accessibility structure. ## 📰 Newsletter Ever exported a "perfectly accessible" Word doc to PDF and had it come out broken for screen reader users? Samantha Merrett (UK Ministry of Justice) opened WordPress Accessibility Day 2025 with a document-accessibility session built around one rule: choose your format before you write anything, because conversion is where accessibility dies. Her stance on PDFs is blunt — "my answer pretty much most of the time is no" — backed by a testimonial from an assistive-technology user who finds more than half of PDFs frustrating to read. The session is a genuinely usable checklist: real style-based headings (not bold, size-28 text), tables that are never screenshots, headers/footers screen readers skip by default, context-specific alt text instead of software auto-generation, descriptive link text, unique slide titles, and never using color alone to signal meaning. Q&A covers free PDF tools beyond Acrobat (PAC, PAVE) and confirms what many suspected: PowerPoint-to-PDF exports are not built to be accessible, whichever office suite you use. Full session: [WordPress Accessibility Day 2025](https://2025.wpaccessibilityday.org/). ## ✅ Action Items #### DevRel - Education: package the format-choice framework (who/how/how-shared) and the headings-plus-alt-text beginner fix (t=2647s–2659s) into a 30-minute office-hours workshop for contributor-day and WordCamp organizers who produce handouts and slide decks. #### OSPO - Not applicable to this source — the talk covers desktop document (Word/PowerPoint/Excel/PDF) accessibility, not repository licensing, SBOM, or contribution governance. #### Community - Maintainers: not applicable — no project-maintenance content in this source. - Contributors: not applicable — no contributor-onboarding content in this source. - Sponsors: not applicable — sponsor list (Gravity Forms, WP Engine, Woo, Equalize Digital, etc.) is event-level, not discussed as content. - Ecosystem: WordPress community events (WordCamps, WordPress Accessibility Day itself) could require speaker decks to follow Merrett's master-slide, unique-title, and color-alone rules before publishing session recordings. #### WordPress - Core: not applicable — talk addresses desktop office documents, not WordPress core software. - Core Performance: not applicable — no performance content. - Core AI: any AI-assisted alt-text feature should add a human-review step — Merrett found software auto-generated alt text "not necessarily great at getting it right" and always double-checks it (t=1478s–1487s). - **Core Program Team:** not applicable — no cross-team coordination content. - Mobile: not applicable — talk addresses desktop Office/PDF workflows, not the WordPress mobile app. - Playground: not applicable — no browser-based demo content. - Community: WordCamp organizers can apply the three-question format framework (who/how/how-shared) when deciding whether a handout should be a Word doc, a web page, or a PDF. - Training: Learn WordPress could host Merrett's Word/PowerPoint/Excel checklist as a standalone lesson alongside existing accessibility content. - Marketing: not applicable — no campaign or content-funnel material in this source. - Support: not applicable — no support-ticket workflow content. - Design: apply the "never indicate with color alone" rule (t=1860s–1885s) and unique-title discipline to block pattern and template library defaults. - Documentation: HelpHub/DevHub could add a "creating accessible downloadable documents" guide covering headings, tables, and alt text, mirroring this talk's structure. - Photos: not applicable — the alt-text guidance here is document-specific; the Photos directory runs its own metadata/submission workflow. - TV: not applicable — talk covers document accessibility, not video captioning (WordPress.tv's own domain). - Polyglots: not applicable — no translation or locale content. - Accessibility: this talk is direct source material — build a document-accessibility audit checklist and map it to WCAG 2.2 AA criteria (see Accessibility Assessment below) for use in WordPress.org's own downloadable resources. - Meta: not applicable — no .org roadmap or infrastructure content. - CLI: not applicable — no command-line content. - Hosting: not applicable — hosting companies (GoDaddy, GreenGeeks, SiteGround) appear only as event sponsors, not discussed as content. - Tide: not applicable — no plugin-scanning content. - Openverse: consider Merrett's caution about unreviewed auto-generated alt text (t=1478s–1487s) if Openverse adds AI-assisted image descriptions. - Themes: not applicable — no theme-review content. - Plugins: not applicable — no plugin-review content; Equalize Digital (an accessibility-checker plugin maker) appears only as a Gold sponsor, not discussed. #### The WPOCC - Programs: not directly applicable — this is a training session, not a WPOCC funding or governance topic, though The WPOCC could commission similarly practical accessibility trainings for its programs. ### FAIR - Technical independence: not applicable — the talk addresses document format and structure, not FAIR's federated governance, provenance, or plugin-signing mechanics. ## 🧪 Hypotheses - H1: Documents built with real style-based Heading 1–N structure reduce screen-reader navigation time versus documents using bold/large-font pseudo-headings (t=1076s–1092s). - H2: Converting a source Word document to PDF introduces measurable tag, reading-order, or alt-text defects at a materially higher rate than distributing the Word file directly (t=421s–432s, t=926s–943s). - H3: PowerPoint's and Acrobat's built-in accessibility checkers flag stark color-contrast failures at a much higher rate than near-threshold contrast failures or generic link text ("click here") (t=2760s–2799s). - H4: PDF compression through common third-party tools removes tags, alt text, or metadata at a rate that varies significantly by tool and compression method (t=2836s–2862s). - H5: Multi-sheet Excel workbooks with a hyperlinked index sheet reduce the time screen-reader users need to locate a specific data sheet, versus workbooks without one (t=1919s–1939s). ### 📊 Methodology - H1/H5: task-based usability testing with screen-reader users (JAWS, NVDA, VoiceOver), timing navigation to a target section/sheet, comparing structured vs. unstructured document variants. - H2/H4: automated + manual accessibility audits (tag tree inspection, alt-text presence, reading-order checks) run before and after each conversion or compression step, across a sample of real documents. - H3: run a set of documents with known contrast ratios (some clearly failing, some near the 4.5:1/3:1 thresholds) and known link-text patterns through each checker, then compare flagged vs. actual failures against a manual WCAG 2.2 audit. ### ❓ Questions - Will WCAG 3.0 formally adopt the "access for as many people as possible" framing Merrett cites as still "rumored" and in progress (t=524s–537s)? - What's the actual defect rate — tags, reading order, alt text — introduced specifically by PowerPoint-to-PDF export versus Word-to-PDF export, across major screen readers? - How does Google Workspace's document/slide/sheet accessibility compare to Microsoft Office's on the same structural criteria Merrett lays out (headings, tables, alt text, color)? - What share of "fully automated" PDF remediation tools actually meet PDF/UA compliance without manual follow-up, versus advertising it? ### 🔮 Future Research - No data is cited in the talk on PDF failure rates beyond one testimonial (t=881s–890s) — a quantitative study across UK public-sector PDFs would test the claim more rigorously. - No cross-office-suite comparison (Microsoft vs. Google vs. LibreOffice) is offered, despite the guidance being framed as suite-agnostic (t=980s–995s). - No study is cited on neurodivergent users' actual response to the spacing/bold/italic/underline guidance (t=1648s–1659s) — the recommendations are presented as established practice without a named source. ### 💡 Implications - **Practice:** organizations can adopt a "Word first, PDF only when justified" default policy, cutting the volume of documents needing separate PDF remediation. - **Policy:** UK public-sector bodies face accessibility law directly (t=543s–550s); non-UK organizations following this guidance do so voluntarily unless bound by equivalent statutes (ADA, EN 301 549, AODA). - **Security:** not discussed in this source — the talk touches document metadata only in the context of PDF compression removing titles/authors (t=2862s), not data protection or exposure. - **Education:** the format-choice framework and headings-plus-alt-text priority (t=2647s–2659s) form a low-effort entry point for beginner training curricula. - **Funding:** not discussed in this source — no funding or budget model appears in the talk. ### 🧠 Learning Styles Assessment - Reading level estimate: Flesch-Kincaid Grade Level, estimated grade 6–7. Basis: short, contraction-heavy spoken sentences ("It's also the law," "How do I do that?"), plain vocabulary, minimal subordinate clauses — typical of a live, conversational conference talk rather than written technical prose. #### 👀 Visual learners - Present: the speaker continuously describes slide visuals aloud (dog images, alt-text examples, color-circle example) but the transcript itself carries no diagrams, screenshots, or labeled figures. - Improve: a companion PDF/slide handout with the actual before/after Word and PowerPoint screenshots she references would let visual learners see the fixes, not just hear them described. #### 🔊 Aural learners - Present: the entire source is a spoken conference talk with live audio description of every image — a strong native fit for aural learners. - Improve: a standalone 3–5 minute audio recap of the six top rules (headings, tables, alt text, links, color, no-PDF-by-default) would serve aural learners who want a refresher without the full 40 minutes. #### 🗣️ Verbal learners - Present: she defines terms as she introduces them ("accessible document," "alt text," "AT users") and gives concrete before/after examples (the alt-text walkthrough, t=1538s–1591s). - Improve: a short glossary (WCAG, PDF/UA, AT, screen reader) alongside the note would help readers unfamiliar with the acronyms she uses without expansion. #### 🧩 Kinesthetic learners - Present: step-by-step actionable instructions throughout ("right-click, choose Properties, add alt text," t=1464s–1470s). - Improve: a checklist artifact (checkbox per rule: headings, tables, alt text, links, color, spacing) would let kinesthetic learners work through a real document while following along. #### 🧠 Logical learners - Present: the three-question decision framework for format choice (who/how/how-shared, t=600s–610s) is a clean decision tree. - Improve: a table mapping document type → primary risk → fix (e.g., PDF → tag loss → verify with PAC) would suit logical learners better than prose. #### 🧑‍🤝‍🧑 Social learners - Present: the live Q&A format models collaborative problem-solving with real audience questions. - Improve: a discussion-prompt version of the Q&A ("bring one document from your own work and identify its biggest accessibility gap") would extend the social-learning value beyond a single live session. #### 🧘‍♀️ Solitary learners - Present: the talk is structured as a self-contained sequence (format choice → Word → PowerPoint → Excel → best practices) that a solitary learner can follow at their own pace from a recording. - Improve: self-check questions after each section ("does your last document have a real Heading 1?") would support solitary, self-paced review. #### 🌿 Naturalistic learners - Present: not applicable — no sustainability, environment, or ecosystem framing appears in the talk. - Improve: none identified; this learning style doesn't map naturally onto document-accessibility content. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Merrett models the practice she teaches by audio-describing every slide image live (e.g., t=316s–334s, t=1532s–1591s) — a genuine strength of the source itself. - Improve (WCAG 2.2 AA, 1.1.1 Non-text Content / 4.1.2 Name, Role, Value): the original video would benefit from chapter markers using the same "unique, descriptive title" discipline the speaker recommends for slides (t=1748s–1786s). #### Keyboard navigation - Present: delivered on YouTube/Zoom, both natively keyboard-operable video platforms. - Improve: not applicable to this source — no interactive on-screen elements beyond standard video player controls. #### Contrast and readability - Present: cannot be verified from the transcript alone — slide visuals (color circles, fonts) aren't assessable from audio/text. - Improve (WCAG 2.2 AA, 1.4.3 Contrast Minimum / 1.4.11 Non-text Contrast): a visual accessibility pass on the original slide deck against the 4.5:1 text-contrast threshold Merrett herself teaches (t=2772s–2784s) is recommended but not verifiable here. #### Text resizing and reflow - Present: not assessable from a video/transcript source. - Improve: not applicable — no reflow-dependent content in this source format. #### Media and captions - Present: a full timestamped transcript exists (this document's source), and the speaker models audio description live. - Improve (WCAG 2.2 AA, 1.2.2 Captions (Prerecorded)): confirm the published YouTube video carries accurate closed captions (not only auto-generated) and a downloadable transcript, matching the live-event practice Merrett models. #### Forms and interactions - Present: not applicable — no interactive forms in this video content. - Improve: not applicable. #### Standards reference - Maps primarily to WCAG 2.2 AA: 1.1.1 (Non-text Content — alt text, modeled live by the speaker), 1.3.1 (Info and Relationships — heading and table structure, the talk's central topic), 1.4.1 (Use of Color — "never indicate with color alone," t=1856s–1885s), 1.4.3/1.4.11 (contrast, referenced but not independently verifiable here), 2.4.6 (Headings and Labels — descriptive headings/slide titles), 2.4.4 (Link Purpose — descriptive link text, t=1608s–1630s), 1.2.2 (Captions for the video itself). ### 🌍 DEIB Assessment #### Cultural breadth - Present: examples are consistently UK-centric (UK Ministry of Justice, UK government PDF practice, UK law, t=272s–566s); no non-UK regulatory or cultural examples appear. - Improve: adding a brief comparison to other jurisdictions' document-accessibility requirements (ADA/Section 508 in the US, EN 301 549 in the EU) would broaden applicability for a global WordPress audience. #### Inclusive language - Present: states pronouns (she/her) and gives a visual self-description at the start (t=294s–300s) — a widely recommended accessibility-community practice that most conference speakers skip. - Improve: none significant identified; the practice modeled here is already strong. #### Neurodiversity support - Present: explicitly dedicates a segment to neurodiversity-friendly formatting — plain English, minimal bold/italic/underline, color contrast (t=1633s–1659s). - Improve: the talk itself moves quickly through a dense 40-minute agenda (acknowledged by the speaker herself, t=2639s–2645s); chunking a companion written version into shorter labeled sections would better serve neurodivergent readers processing it as text. #### Representation - Present: single presenter; personal-life disclosure (dog, fiancé, travel, yoga) is used to build rapport rather than to represent multiple identities or roles. - Improve: citing or naming more than one assistive-technology user's testimonial (only one is quoted, t=881s–890s) would represent a broader range of AT-user experience. #### Psychological safety - Present: warm, low-pressure tone throughout; explicit content disclaimer about the recurring dog images (t=245s–259s); the "How about no" and grumpy-dog memes soften otherwise blunt guidance (e.g., discouraging PDFs) without shaming past practice. - Improve: none significant identified. ### ✅ Logical Validity #### Strong reasoning - **Causal reasoning, format-conversion risk (t=421s–432s):** Merrett's core claim — that an accessible document can become inaccessible purely through export/conversion — is a specific, testable causal mechanism (tag loss, reading-order disruption), not a vague warning, and it's the reason she puts format choice first. - **Appropriately scoped inductive claim (t=881s–890s, t=892s–897s):** she cites a single assistive-technology-user testimonial about PDF frustration, then explicitly hedges the generalization — "I think that's quite common feeling" — rather than asserting the testimonial proves a universal pattern. This is a correctly bounded use of anecdotal evidence. - **Consistent decision framework (t=600s–646s):** the three-question format-choice model (who/how/how-shared) is applied consistently across every format discussed afterward (PowerPoint, Excel, Word, PDF), giving the talk's structure internal logical consistency. #### Fallacies - No fallacies identified. The talk stays within claims Merrett can support from her stated professional experience (UK Ministry of Justice document remediation and training) and repeatedly signals the limits of her own certainty — "it depends," "I don't use any of them myself, so I can't recommend one or the other" (t=2426s–2431s), "unfortunately I can't say yes or no" (t=2830s–2833s). Where she generalizes from a single data point (the PDF testimonial), she hedges rather than overclaiming, which is the fix that would otherwise be needed for a hasty-generalization fallacy. #### Tone of voice - Conversational, warm, and self-deprecating in places ("Enough of the negative though," t=1303s–1304s); direct and unhedged on core recommendations ("please do not add tables as images," t=1164s–1178s) but explicitly hedged on uncertain or context-dependent questions (PDF compression, third-party tool recommendations). Uses recurring dog-meme humor as a tension release between blunt corrective points. ### 🛡️ DARVO Analysis - **Deny:** not applicable to this source — no accusation exists for Merrett to deny; the talk is instructional, not a response to a complaint. - **Attack:** not applicable to this source — no critic or accuser is named or attacked; disagreement (e.g., "no, Adobe Acrobat is definitely not the only proper tool," t=2338s–2343s) is a factual correction of a questioner's premise, not a credibility attack. - **Reverse victim/offender:** not applicable to this source — no victim/offender framing appears; the closest emotional content is empathetic ("I always open a PDF with trepidation," a quoted AT user's own experience, t=881s–890s), not a reversal of blame. ## 🎯 Conclusion - **Bottom line:** accessible documents start with a format decision, not a formatting pass — Merrett's framework is choose Word by default, avoid PDF unless justified, use real style-based headings and tables, write context-specific alt text, and test throughout creation rather than at the end. - **Practical next steps:** audit one existing document against the six core rules (headings, tables, headers/footers, spacing, alt text, link text); if it's a PDF, run it through PAC or Acrobat's checker and compare against a manual pass for near-threshold contrast and link text the checker will miss; and default new documents to Word unless the three-question format test (who/how/how-shared) points elsewhere. ## 🔄 Refactor Appendix — The Art of Accessibility: Making Documents Delightfully Inclusive ### 📚 Literature Atoms (H3) #### [H1] Accessible documents stay in their native Word format > [!quote] ID:rw_wpa11yday2025-1 > if it's made in Word, it can stay in Word. **Context & use**: - t=759s, during the "choosing the right format" section. - Anchors the talk's default recommendation: Word converts cleanly, stays flexible, and works well with assistive technology, so conversion (the risk point for accessibility) is avoided by default. **Tags**: #xref **Highlight**: [view highlight](readwise://open?doc_id=01m21cz2cjrmz72g8syhk29tg0)  #### [H2] PDF is the default wrong choice for accessibility > [!quote] ID:rw_wpa11yday2025-2 > My answer pretty much most of the time is no. **Context & use**: - t=860s, answering her own rhetorical question "should I create a PDF with that?" - Sets up the assistive-technology-user testimonial that follows immediately (t=881s–890s) as supporting evidence. **Tags**: #xref **Highlight**: [view highlight](readwise://open?doc_id=01m21cz2cjrmz72g8syhk29tg0)  #### [H3] Headings are the structural backbone of a document > [!quote] ID:rw_wpa11yday2025-3 > Headings are the backbone of any document. **Context & use**: - t=1008s, opening the headings section, later echoed in Q&A as the single most common accessibility mistake (t=2583s–2609s). - Grounds the claim that scanability and screen-reader navigation both depend on real heading structure, not visual imitation. **Tags**: #xref **Highlight**: [view highlight](readwise://open?doc_id=01m21cz2cjrmz72g8syhk29tg0)  #### [H4] Alt text must match the specific context, not a generic template > [!quote] ID:rw_wpa11yday2025-4 > Alt text is very context-dependent **Context & use**: - t=1484s, immediately before the live example contrasting "Image 342.jpg," "Dog with its mouth wide open," and a fuller emotional description (t=1538s–1591s). - Supports the caution against relying on software-automated alt text without human review (t=1478s–1487s). **Tags**: #xref **Highlight**: [view highlight](readwise://open?doc_id=01m21cz2cjrmz72g8syhk29tg0)  #### [H5] Tables pasted as images are completely inaccessible > [!quote] ID:rw_wpa11yday2025-5 > please do not add tables as images into your document. **Context & use**: - t=1168s, opening the accessible-tables section. - Frames the strongest absolute rule in the table-formatting guidance — no alt text can fully substitute for real table markup. **Tags**: #xref **Highlight**: [view highlight](readwise://open?doc_id=01m21cz2cjrmz72g8syhk29tg0)  ### 🧠 Permanent Candidates (H4) #### [P1] Format choice is the first accessibility decision **Claim** (one sentence, Courtney's voice): The accessibility of a document is decided at format-choice time, before any content exists, because conversion between formats is where accessible structure gets destroyed. **Evidence pointer**: [[#H1]] — "if it's made in Word, it can stay in Word" **Scope & conditions**: Holds for files distributed as documents (Word/PDF/PowerPoint/Excel); doesn't apply to content authored natively as a web page, where there's no conversion step to lose structure at. **Links** (≥1 with annotation): - [[WCAG 2.2]] — because extends (1.3.1 Info and Relationships depends on the structure format choice preserves or destroys) - [[PDF remediation]] — because contrasts (remediating after the fact vs. choosing the right format from the start)  #### [P2] Accessibility checkers are a floor, not a ceiling **Claim** (one sentence, Courtney's voice): Automated accessibility checkers catch the obvious structural failures but consistently miss context-dependent problems — near-threshold color contrast and generic link text — so a manual pass stays mandatory even after a document passes the checker. **Evidence pointer**: [[#H5]] — table-as-image rule, an example of a rule a checker can't verify from output alone **Scope & conditions**: Applies to built-in checkers (PowerPoint, Acrobat) as evaluated in this talk (t=2760s–2799s); may not generalize to third-party tools not discussed here. **Links** (≥1 with annotation): - [[WCAG 2.2]] — because applies-in (1.4.3 Contrast Minimum, 2.4.4 Link Purpose — both cited as checker blind spots)  ### ✏️ Fleeting Queue - [F1] Compare PAC, PAVE, CommonLook PDF, Axes 4, and Equidox for a WPOCC/FAIR-adjacent document-remediation workflow — https://www.youtube.com/watch?v=-2i6LX7L9HY&t=2417s #fleeting #inbox - [F2] Check whether courtneyr.dev's own downloadable PDFs follow the "keep it in Word, avoid PDF by default" guidance or need remediation #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Audit courtneyr.dev/WPOCC downloadable PDFs against Merrett's PDF-avoidance and remediation guidance — accessibility #things - [ ] Add a heading-structure and context-specific-alt-text check to the pre-publish content checklist — accessibility #things  📄 **Full text:** [[Full Document Contents/Articles/The Art of Accessibility Making Documents Delightfully Inclusive.md|The Art of Accessibility: Making Documents Delightfully Inclusive by Samantha Merrett]] ## Highlights - but you could think of any kind of software that you use, it would be the same type premise. What we tend to say in our organization is if it's made in Word, it can stay in Word. There are very few instances where converting that Word document into another file format is beneficial, so it's always better to keep it in Word if you've created it there. If you're in doubt about what document format to use then maybe opt for Word because 9 times out of 10, it's going to be the most suitable format. ([View Highlight](https://read.readwise.io/read/01m21etrh192gt3gy6j5zwvyb2)) - Note: UK Ministry of Justice house rule: "if it's made in Word, it can stay in Word." Format choice is the first accessibility decision, made before any content exists — conversion is where accessible documents usually break. - Tags: atom/literature/h1, pdf-accessibility, document-accessibility