Accessibility Isn’t Extra Work. It’s Risk Management.  🔗 **Source:** [Accessibility Isn’t Extra Work. It’s Risk Management.](https://www.youtube.com/watch?v=nHsdiAXSusU) > [!note]+ Document Notes > tags: [accessibility, wordpress, risk-management, wcag-compliance, legal-compliance, developer-workflow] > author: Jennifer Wjertzoch > source: WordPress Accessibility Day 2025 > reference: https://www.youtube.com/watch?v=nHsdiAXSusU > 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: Accessibility Isn't Extra Work. It's Risk Management. > <!-- deep-read:sections start --> ## 🧭 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--accessibility-isnt-extra-work-its-risk-management) ### 🔗 References (in-page) - [WordPress Accessibility Day 2025 video](https://www.youtube.com/watch?v=nHsdiAXSusU) - [WebAIM Million Report (2025)](https://webaim.org/projects/million/) — cited stat: 95% of homepages carry errors, 51 per page on average - [UsableNet 2025 Midyear ADA lawsuit report](https://usablenet.com/) — cited stat: 2,019 ADA lawsuits filed in the first six months of 2025 ## 📝 Summary - **What happened**: Jennifer Wjertzoch, a senior front-end engineer at DKB Code Factory in Berlin, gave a talk at WordPress Accessibility Day 2025 arguing that WordPress teams should treat accessibility as risk management rather than an optional design polish step. - **Why it matters**: WordPress powers more than 43% of all websites, per her figures, yet accessibility checks are "rarely a fixed part of the process" on WordPress projects — a gap she says creates avoidable legal, business, and reputational exposure. - **Key stakeholders**: WordPress theme and plugin authors, agency and in-house dev teams, content editors, designers, and the "accessibility lead" role she proposes as an ownership function. - **Risks and tradeoffs**: Legal (ADA/EAA/BFSG lawsuits — 2,019 filed in the US in H1 2025 alone, per UsableNet), reputational (the 2021 UK National Rail "Grayscale incident"), and business (Forrester's finding that late fixes cost up to 10x more than design-phase fixes). - **Bottom line**: Her proposed fix is a three-part workflow — a 60-second keyboard "supply chain" check before adopting any theme or plugin, CI accessibility gates (Axe-Core, PA11Y) that block merges, and "Defense in Depth" (accessible patterns baked in at concept, contrast checked on real backgrounds, focus states designed on purpose) — plus a named accessibility lead and a one-hour editor training to keep it from decaying after launch. ## 📖 Main Content Wjertzoch frames her argument through her own career: a "traditional German brand" digitization job at Oetker Digital (where she helped build a shared design system so "every team that uses those components ships accessibility features by default"), fast-moving agency work at Jung von Matt TECH, and her current role building Vue front-ends for financial products at DKB Code Factory, where "no feature goes live without an accessibility review." Her thesis is that WordPress projects would run "smoother," "faster," and "safer" if they borrowed the banking industry's "nothing ships without" compliance discipline. She grounds the argument in numbers: the 2025 WebAIM Million Report found 95% of homepages still carry accessibility errors, averaging 51 per page — and she says these are "not advanced or complicated," just missing alt text, unlabeled buttons/links, poor contrast, and keyboard traps. She then reframes accessibility around a word she says gets skipped: risk, broken into legal, reputational, and business categories. **Legal risk**: the European Accessibility Act, Germany's Barrierefreiheitsstärkungsgesetz, and the US ADA now bind private companies, not just governments. UsableNet's 2025 Midyear report counted 2,019 ADA lawsuits in the first six months of 2025 alone — about 20% higher than the same period the prior year — naming Domino's Pizza (blind users couldn't order via site/app; court upheld the plaintiffs), Target (site didn't work for blind customers), Netflix (missing closed captions), and Beyoncé's website (inaccessible to blind users) as defendants. **Reputational risk**: she tells the story of the April 2021 "Grayscale incident" — when Prince Philip died, UK rail operators National Rail, CrossCountry, and Northern Rail turned their websites black-and-white in mourning, making timetables unreadable. The RNIB (Royal National Institute of Blind People) had to publicly remind them that "contrast isn't a design choice; it's basic usability," and the operators apologized and reverted within days. **Business risk**: citing Forrester Research, she says late accessibility fixes "can cost up to 10 times more" than early ones, and illustrates it with an escalating-cost analogy: about €5 to fix in design, €20 in development, €50+ post-launch. She then walks through what she calls the "WordPress accessibility pattern" — a satirical narrative of how projects actually go live inaccessible: designers skip focus states, developers hard-code under deadline pressure and push a11y tickets to the backlog, content teams migrate hundreds of pages with no alt text and broken heading hierarchies ("H1 to H4, H6"), and at launch someone finally asks if anyone checked accessibility, at which point it gets deferred to a "phase 2" that never happens. From this she extracts four recurring WordPress-specific problems: (1) inconsistent theme/plugin quality — she cites an audit finding over 70% of popular WordPress themes fail basic accessibility criteria out of the box, and describes a real inaccessible autoplay image slider with no focus indicators or pause control; (2) "content churn," where most accessibility regressions on large sites are introduced after launch through ordinary content edits, not at initial coding; (3) unclear ownership, where designers, developers, content authors, and compliance each assume someone else is handling it; and (4) content itself as a barrier — WCAG's lower-secondary reading-level criteria, illustrated with banking jargon (EZB license, SCA authentication, effective APR) and Germany's legal requirement for government sites to offer "easy language" (Leichte Sprache). Her proposed fix has three parts. First, treat themes and plugins as a "supply chain": a 60-second keyboard test before adopting any of them (tab through interactive elements, activate with Enter/Space, close modals with Escape, confirm visible focus) — "if you lose your focus, your users will, too." Second, make accessibility "binding in development" the way unit tests already are, using Axe-Core and PA11Y in CI to block merges on critical errors. Third, "Defense in Depth" — accessible patterns defined at the concept phase, contrast tested on real brand backgrounds (not just Figma), and focus states designed intentionally rather than left as an afterthought. She adds a content layer (a one-hour editor training covering alt text, heading structure, and meaningful link text, plus a Gutenberg heading-hierarchy checker) and an ownership layer — a named "accessibility lead" who monitors CI gates, verifies QA includes real screen-reader/keyboard checks, and runs role-specific training, without being solely responsible for all the work. In Q&A she rejects accessibility overlay plugins like Eye-Able (they don't fix underlying code, can hide real issues, and regulators don't accept them as compliance), takes a "clarity first, inclusion second" position on German gender-inclusive language when it conflicts with screen-reader readability, agrees design education under-teaches accessibility, and calls "we don't have users with disabilities" the worst argument against prioritizing it, comparing it to claiming a site has no mobile users because it doesn't work on mobile. **Uncertainties/contested claims**: The "70% of themes fail" and "51 errors per page" figures are cited without a named source/methodology beyond "when experts audited popular WordPress themes" and the WebAIM Million Report respectively — the WebAIM figure is attributable and checkable, the theme-audit figure is not sourced by name in the talk. Her claim that "more and more banks are moving away from WordPress towards platforms where compliance and accessibility governance are built in from the start" is asserted without data or named examples. ## 🗒️ Notes #### ⏱️ [00:01:32](https://www.youtube.com/watch?v=nHsdiAXSusU&t=92s) Annabelle Drumm introduces Jennifer Wjertzoch - Host: Annabelle Drumm, knitwear designer (DrummRoll Knitwear), emceeing WordPress Accessibility Day 2025. - Bio: Jennifer Wjertzoch, front-end engineer specializing in Vue; prior roles at Oetker Digital (40+ international site migration to a modern content management system) and Jung von Matt TECH (brand experiences for clients including LichtBlick and Fehlmann); currently senior front-end engineer at DKB Code Factory, Berlin, building Vue 3 financial-product front-ends. #### ⏱️ [00:03:51](https://www.youtube.com/watch?v=nHsdiAXSusU&t=231s) Career arc: Oetker Digital and design-system foundations - At Oetker Digital, her team built one shared design system so components with "proper semantics, focus handling, error handling, and keyboard support" ship accessible by default across teams. - Jung von Matt TECH taught her agile, short-iteration shipping — "that's also where I met WordPress in practice." #### ⏱️ [00:05:20](https://www.youtube.com/watch?v=nHsdiAXSusU&t=320s) Banking at DKB: accessibility as compliance, not extra work - At DKB, every feature "has to tick the basics": safe, compliant, accessible. > [!quote] > No feature goes live without an accessibility review. - Frames accessibility as simultaneously a compliance, governance, and risk decision. #### ⏱️ [00:08:08](https://www.youtube.com/watch?v=nHsdiAXSusU&t=488s) WebAIM Million 2025: 95% of homepages fail, 51 errors average - WordPress runs "more than 43%" of all websites (stated just before this point, t=444s). > [!quote] > 95% of homepages still have accessibility errors. - Average of 51 errors per page; most common WordPress errors named: images without alt text, unlabeled buttons/links, poor color contrast, keyboard navigation barriers. #### ⏱️ [00:10:12](https://www.youtube.com/watch?v=nHsdiAXSusU&t=612s) Naming the risk framing: legal, business, reputational - Introduces "risk" as the underused word next to accessibility, and names three categories from her financial-industry experience: legal, business, reputational. #### ⏱️ [00:11:34](https://www.youtube.com/watch?v=nHsdiAXSusU&t=694s) Legal risk: EAA, BFSG, ADA, and 2,019 H1 2025 lawsuits - Names three laws: the European Accessibility Act, Germany's Barrierefreiheitsstärkungsgesetz, and the US ADA — all now binding on private companies, not just governments. > [!quote] > there were already 2,019 ADA lawsuits filed against websites - Source: UsableNet 2025 Midyear report; ~20% higher than the same period the prior year. #### ⏱️ [00:12:09](https://www.youtube.com/watch?v=nHsdiAXSusU&t=729s) Lawsuit examples: Domino's, Target, Netflix, Beyoncé - Domino's: blind users couldn't order via site/app; court upheld their right to equal access. - Target: site didn't work for blind customers. - Netflix: sued for missing closed captions. - Beyoncé's website: sued for being inaccessible to blind users. #### ⏱️ [00:13:11](https://www.youtube.com/watch?v=nHsdiAXSusU&t=791s) Reputational risk: the National Rail Grayscale incident - April 2021: after Prince Philip's death, National Rail, CrossCountry, and Northern Rail turned their sites black-and-white for mourning, breaking timetable readability. > [!quote] > contrast isn't a design choice; it's basic usability. - Quote attributed to the RNIB (Royal National Institute of Blind People), which had to intervene; operators apologized and reverted within days. #### ⏱️ [00:16:19](https://www.youtube.com/watch?v=nHsdiAXSusU&t=979s) Business risk: Forrester's 10x cost-escalation model > [!quote] > late fixes can cost up to 10 times more - Cost analogy: ~€5 to fix in design phase, ~€20 in development, ~€50+ at launch. > [!quote] > compliance can't be a plugin, and accessibility can't be a plugin either - Claims (unsourced in the talk) that banks are moving away from WordPress toward platforms with built-in compliance/accessibility governance. #### ⏱️ [00:18:39](https://www.youtube.com/watch?v=nHsdiAXSusU&t=1119s) The WordPress accessibility pattern: a real project walkthrough - Narrative arc: design phase skips focus states ("Yes, we didn't design those"); dev phase hard-codes under deadline pressure and defers a11y tickets to the backlog. #### ⏱️ [00:19:51](https://www.youtube.com/watch?v=nHsdiAXSusU&t=1191s) Content migration: alt text and heading chaos - Migrating 400 pages of old content produces images with no alt text, headings jumping "H1 to H4, H6," and 10 different "Read more" links on one page — deferred as "we'll clean that up later." #### ⏱️ [00:20:32](https://www.youtube.com/watch?v=nHsdiAXSusU&t=1232s) Launch day: "did anyone check accessibility?" - At the celebratory launch moment, someone finally asks if accessibility was checked; the project manager defers it to a "phase 2" that, per Wjertzoch, is code for never happening. #### ⏱️ [00:21:52](https://www.youtube.com/watch?v=nHsdiAXSusU&t=1312s) Challenge 1: importing bad code from themes and plugins - WordPress core and official accessibility-ready themes are a solid base; community themes/third-party plugins are unpredictable. #### ⏱️ [00:22:25](https://www.youtube.com/watch?v=nHsdiAXSusU&t=1345s) Stat: over 70% of audited themes fail basic criteria > [!quote] > over 70% failed on basic accessibility criteria out of the box #### ⏱️ [00:22:51](https://www.youtube.com/watch?v=nHsdiAXSusU&t=1371s) The inaccessible image slider example - A real project's autoplay image slider: smooth animations, but no focus indicators, no pause control, no meaningful labels — "the slider wasn't a feature; it was simply a wall," and a compliance risk for the business behind it. #### ⏱️ [00:23:37](https://www.youtube.com/watch?v=nHsdiAXSusU&t=1417s) Challenge 2: content churn after launch - Most accessibility issues on large sites are introduced after launch through everyday content updates, not coded in at build time — confirmed, she says, when auditing sites that were originally delivered accessibly. #### ⏱️ [00:24:56](https://www.youtube.com/watch?v=nHsdiAXSusU&t=1496s) Challenge 3: unclear ownership - Designers assume developers will handle it; developers assume content authors will; content authors assume compliance will check it. "If even one link in this chain is weak, the result will not be accessible." #### ⏱️ [00:25:50](https://www.youtube.com/watch?v=nHsdiAXSusU&t=1550s) Challenge 4: content and jargon as a barrier - WCAG criteria call for lower-secondary reading level content; jargon examples: EZB license, SCA authentication, effective APR. - Germany legally requires government sites to offer "easy language" (Leichte Sprache); a 2025 accessibility survey was itself criticized by a participant for overly complicated wording. #### ⏱️ [00:28:51](https://www.youtube.com/watch?v=nHsdiAXSusU&t=1731s) Idea 1: treat themes and plugins as a supply chain - Coffee-supply-chain analogy: if any link (moldy beans, bad roasting) breaks, the end product suffers. Themes/plugins are WordPress's dependencies and should get the same vetting security teams already apply. #### ⏱️ [00:30:17](https://www.youtube.com/watch?v=nHsdiAXSusU&t=1817s) The 60-second keyboard test - Gate before adopting any theme/plugin: tab through all interactive elements in a sensible order, activate buttons/links with Enter/Space, close modals/dropdowns with Escape, confirm focus is always visible. > [!quote] > If you lose your focus, your users will, too. #### ⏱️ [00:31:19](https://www.youtube.com/watch?v=nHsdiAXSusU&t=1879s) Idea 2: CI gates with Axe-Core and PA11Y - Treat critical accessibility errors like failing unit tests — block the merge. Named tools: Axe-Core, PA11Y. Framed as catching "the easy stuff reliably," not everything. #### ⏱️ [00:32:13](https://www.youtube.com/watch?v=nHsdiAXSusU&t=1933s) Idea 3: Defense in Depth - Multi-layered protection across every project phase, starting with defining accessible interaction patterns (keyboard order, screen-reader announcements) at the concept stage — then contrast testing on real brand backgrounds and intentional, purposeful focus states. #### ⏱️ [00:34:38](https://www.youtube.com/watch?v=nHsdiAXSusU&t=2078s) Editorial layer: one-hour editor training - Covers three things: alt text, heading hierarchy, and meaningful link text (not "click here"). Pairs with a Gutenberg heading-hierarchy checker that warns on skipped levels (e.g., H2 to H4). #### ⏱️ [00:37:01](https://www.youtube.com/watch?v=nHsdiAXSusU&t=2221s) The accessibility lead role - Five responsibilities: pattern accessibility (UI and code), CI gate monitoring, QA process verification (real screen-reader/keyboard checks, not just "looks fine on Chrome"), clear communication, and role-specific training. > [!quote] > if nobody owns accessibility, it becomes a beautiful idea that slowly fades the moment a project ships #### ⏱️ [00:41:20](https://www.youtube.com/watch?v=nHsdiAXSusU&t=2480s) Closing message: consistency over perfection - Final framing: supply-chain checks, CI gates, Defense in Depth, ownership, and "the human touch" combine into a habit, not a one-time checklist. Goal for WordPress teams: "not perfection, just consistency." #### ⏱️ [00:42:22](https://www.youtube.com/watch?v=nHsdiAXSusU&t=2542s) Q&A: overlay plugins like Eye-Able - Overlays (e.g., Eye-Able) sit on top of a site and simulate fixes (color changes, text-to-speech, fake keyboard navigation) without fixing underlying code; can hide real issues; not accepted by regulators as compliance. #### ⏱️ [00:43:38](https://www.youtube.com/watch?v=nHsdiAXSusU&t=2618s) Q&A: gendered speech in German - On German gender-inclusive language forms that can hurt screen-reader/cognitive readability: "clarity first and then inclusion second," decided case by case. #### ⏱️ [00:44:53](https://www.youtube.com/watch?v=nHsdiAXSusU&t=2693s) Q&A: graphic design and accessibility education - Agrees contrast, typography, and layout are all part of accessibility; says design schools "still teach aesthetics first" and skip the inclusive part, requiring ongoing internal discussion with design departments. #### ⏱️ [00:46:18](https://www.youtube.com/watch?v=nHsdiAXSusU&t=2778s) Q&A: worst argument against accessibility > [!quote] > we don't have users with disabilities or we don't have employees with disabilities - Compares this to claiming a site has no mobile users because it doesn't work on mobile — "you exclude people." ## 📚 References - [WordPress Accessibility Day 2025 — session video](https://www.youtube.com/watch?v=nHsdiAXSusU) - [WebAIM Million Report, 2025 edition](https://webaim.org/projects/million/) — cited for the 95%-of-homepages and 51-errors-per-page figures - [UsableNet 2025 Midyear ADA Web Accessibility Lawsuit Report](https://usablenet.com/) — cited for the 2,019 H1-2025 ADA lawsuit count - [RNIB — Royal National Institute of Blind People](https://www.rnib.org.uk/) — cited as the body that publicly responded to the National Rail Grayscale incident ## 🗣️ Paraphrase Wjertzoch opens by tracing her own path from a traditional German brand (Oetker Digital) through fast-moving agency work (Jung von Matt TECH) to banking (DKB Code Factory), arguing that each stop taught her a piece of what WordPress accessibility needs: order, speed, and a compliance mindset. She uses WebAIM's finding that 95% of homepages carry accessibility errors, averaging 51 per page, to argue that WordPress's openness — the thing that makes it powerful — is also what lets accessibility slip through unchecked, since checks aren't a mandatory part of most WordPress workflows. She then reframes the whole subject around risk rather than quality: legal risk from a rising wave of ADA/EAA/BFSG lawsuits against companies like Domino's, Target, Netflix, and Beyoncé's site; reputational risk illustrated by the UK rail industry's grayscale-website mourning misstep in 2021; and business risk quantified by Forrester's finding that late fixes cost up to 10 times more than early ones. From there she diagnoses four WordPress-specific failure patterns — bad theme/plugin code, content that decays after launch, unclear ownership, and jargon-heavy content — before proposing a three-part fix: vet themes and plugins with a 60-second keyboard test, gate CI on automated accessibility tools, and build "Defense in Depth" by designing accessible patterns, contrast, and focus states from the concept phase onward. She closes by arguing ownership (a named accessibility lead) and editor training are what keep the whole system from decaying, and fields Q&A questions on overlay plugins, gendered language, design education, and the worst excuses she's heard for skipping accessibility. ## 📰 Newsletter Jennifer Wjertzoch (DKB Code Factory, Berlin) brought receipts to WordPress Accessibility Day 2025: 95% of homepages still fail accessibility checks (WebAIM Million, 2025), and 2,019 ADA lawsuits were filed against websites in just the first six months of 2025 (UsableNet). Her fix isn't a plugin — it's a habit. Before you install a theme or plugin, spend 60 seconds tabbing through it: can you reach every interactive element, activate it with Enter/Space, close modals with Escape, and always see focus? If it fails, don't ship it. Pair that with CI gates (Axe-Core, PA11Y) that block a merge on a broken accessible name the same way a failing unit test would, and you've closed the two biggest WordPress-specific gaps she named: over 70% of audited themes failing basic criteria out of the box, and most large-site accessibility issues creeping in after launch through routine content edits, not initial code. Worth a listen if your team still treats accessibility as a phase-2 line item — her point is that "phase 2" is usually code for never. ## ✅ Action Items #### DevRel - Developer advocacy: pitch a WordPress-specific "60-second keyboard test" lightning talk or workshop at a WordCamp, using Wjertzoch's supply-chain framing for theme/plugin vetting. - Education: package the three-layer framework (supply chain check, CI gate, Defense in Depth) as a reusable workshop module with the Axe-Core/PA11Y CI examples she cites. - Developer experience: not directly addressed — the talk names tools (Axe-Core, PA11Y) but gives no code samples, quickstarts, or CI config to reuse as-is. - Developer marketing: not applicable to this source — no campaign or funnel content in the talk. - Community management: not applicable to this source — talk doesn't address moderation or code-of-conduct operations. - Internal/external/cross-project: the "accessibility lead" role she proposes maps directly onto a cross-team SLA/feedback-loop owner; worth citing when defining that role for WordPress teams. #### OSPO - Policy & Governance: cite the talk's "no feature ships without an accessibility review" rule as a model contribution-policy clause for any WordPress-adjacent OSS project. - License Compliance: not applicable to this source — no licensing content in the talk. - Security Management: her "themes and plugins as supply chain" analogy maps directly to existing vuln-intake/dependency-review practice; worth citing when framing accessibility as a security-adjacent discipline. - Software Inventory: not applicable to this source — no SBOM or inventory content. - Developer Support: the one-hour editor training model (alt text, headings, link text) is a reusable template for a lightweight training offering. - Community Engagement: not applicable to this source. - Strategic Alignment: her three risk categories (legal, business, reputational) give OSPO leadership a ready-made framing for reporting accessibility debt as risk, not backlog. #### Community - Maintainers: adopt the 60-second keyboard test as a pre-merge checklist item for theme/plugin repos. - Contributors: the four WordPress-specific failure patterns (bad theme code, content churn, unclear ownership, jargon) are a ready-made "first issue" triage lens for accessibility bugs. - Sponsors: not applicable to this source — no sponsor-facing content beyond the event's own sponsor roll. - Ecosystem: the overlay-plugin Q&A answer (regulators don't accept overlays as compliance) is worth surfacing anywhere the ecosystem debates overlay-based "accessibility" plugins. #### WordPress - Core: consider whether core or a canonical accessibility-ready-theme guideline should formalize the 60-second keyboard test as a submission checklist item. - Core Performance: not applicable to this source — talk doesn't address performance. - Core AI: not applicable to this source. - **Core Program Team:** the "accessibility lead" role description (pattern accessibility, CI monitoring, QA verification, communication, training) is a usable job description template for a cross-team accessibility liaison. - Mobile: not applicable to this source — talk is web/CMS-focused. - Playground: could host a demo Playground blueprint showing the CI-gate pattern (Axe-Core/PA11Y blocking a merge) for training purposes. - Community: candidate WordCamp/meetup session: "Accessibility as risk management," using her three-risk framing. - Training: the one-hour editor training (alt text, headings, link text) and the heading-hierarchy Gutenberg checker are directly reusable as a Learn WordPress lesson. - Marketing: not applicable to this source — no marketing narrative content. - Support: not applicable to this source — talk doesn't address support SLAs. - Design: flag her point that design schools "teach aesthetics first" and skip inclusive design — relevant to any WordPress design-team curriculum or onboarding. - Documentation: consider a HelpHub page distilling the four WordPress-specific failure patterns (theme/plugin quality, content churn, ownership, jargon) into a checklist. - Photos: not applicable to this source. - TV: this talk itself is a WordPress.tv candidate if not already indexed there (it aired at WordPress Accessibility Day 2025). - Polyglots: her "easy language" (Leichte Sprache) example is relevant to any locale-specific plain-language guidance Polyglots produces. - Accessibility: this talk is directly on-topic — cite the four failure-pattern breakdown and the three-part fix in the team's audit/tooling cadence discussions. - Meta: not applicable to this source. - CLI: consider a WP-CLI command or scaffold that runs Axe-Core/PA11Y against a local install as a lightweight version of her CI gate. - Hosting: her claim that banks are moving off WordPress toward platforms with built-in compliance governance is worth fact-checking against real hosting-provider compliance offerings. - Tide: Tide's scoring could incorporate a basic automated accessibility pass, echoing her "over 70% of themes fail" audit finding. - Openverse: not applicable to this source. - Themes: the audited-themes stat (over 70% fail basic criteria) is directly relevant to Theme Review Team criteria discussions. - Plugins: the image-slider example (autoplay, no focus indicators, no pause) is a concrete anti-pattern worth adding to plugin review guidance. #### The WPOCC - Programs: the accessibility-lead role and one-hour editor training are candidate fellowship/microgrant deliverables for a WPOCC-funded accessibility initiative. - Projects: not applicable to this source — talk doesn't name a WPOCC project directly. - Funding experiments: not applicable to this source. ### FAIR - Technical independence: not applicable to this source — talk doesn't address metadata, provenance, or signature checks. - Policies and covenants: her "compliance can't be a plugin" framing is a useful analogy for arguing governance can't be bolted on after the fact — relevant to any FAIR anti-capture covenant language. - Productized governance artifacts: not applicable to this source — no charter or scorecard content. ## 🧪 Hypotheses - H1: WordPress sites built on themes that fail the "60-second keyboard test" before installation have measurably higher WCAG 2.2 AA failure rates than sites where the test gates adoption. - H2: WordPress sites with CI-enforced Axe-Core/PA11Y gates accumulate fewer new accessibility errors per quarter of content updates than sites without CI gates, holding traffic and content volume constant. - H3: Sites with a named "accessibility lead" role show lower rates of the "unclear ownership" failure pattern (measured via time-to-fix on flagged accessibility issues) than sites without one. - H4: The rate of ADA/EAA lawsuit filings against WordPress-built sites tracks the overall ADA lawsuit growth rate (~20% year-over-year per UsableNet) rather than diverging from it. - H5: Editor training limited to alt text, heading hierarchy, and link text meaningfully reduces post-launch "content churn" accessibility regressions on large WordPress sites. ## 📊 Methodology - H1/H2: a matched-pair audit of WordPress theme/plugin installs — one cohort screened with the keyboard test or CI gates, one not — scored against WCAG 2.2 AA automated + manual criteria (Axe-Core plus manual screen-reader pass) at launch and at a 6-month follow-up. - H3: a survey plus issue-tracker analysis across WordPress agencies/teams, correlating presence of a named accessibility-lead role with median time-to-resolution on filed accessibility bugs. - H4: a longitudinal comparison of UsableNet's ADA lawsuit dataset filtered for WordPress-identifiable defendants (via CMS-detection tooling) against the overall dataset trend line. - H5: a pre/post editor-training study on a sample of large WordPress sites, tracking new accessibility errors introduced per month of content publishing before and after a one-hour training rollout. ## ❓ Questions - What specific audit produced the "over 70% of popular WordPress themes fail basic accessibility criteria" figure, and is it reproducible against current wordpress.org theme listings? - Does the WordPress Theme Review Team's current accessibility-ready tag process already catch the failure modes in her image-slider example (autoplay, no pause, no focus indicator), or is that a gap? - How does the "60-second keyboard test" perform against complex components (multi-step forms, custom blocks) versus the simple slider example given? - What does "regulators don't accept them as compliance" mean concretely for overlay plugins — is there a specific regulatory ruling or guidance document she's drawing on? - Is there data on whether banks are actually migrating off WordPress toward more compliance-native platforms, as she claims, or is that anecdotal from her own client work? ## 🔮 Future Research - A reproducible, public audit methodology for WordPress theme accessibility (to validate or update the 70%-fail figure) that the Theme Review Team or an independent researcher could rerun over time. - Empirical tracking of accessibility regression rates on WordPress sites tied specifically to content-editor actions (her "content churn" claim), separate from code-level regressions. - A comparative study of overlay-plugin adoption versus code-level accessibility fixes, tracking lawsuit outcomes for sites using each approach. - Research into whether an "accessibility lead" role, as she defines it, changes measurable outcomes (error rates, time-to-fix) versus diffuse team ownership. ## 💡 Implications - **Practice**: her three-part framework (supply-chain vetting, CI gates, Defense in Depth) is directly implementable by any WordPress team without new tooling spend — Axe-Core and PA11Y are both free/open source. - **Policy**: the legal-risk section (EAA, BFSG, ADA, 2,019 lawsuits in H1 2025) strengthens the case for treating accessibility as a compliance requirement in procurement and vendor-selection policy, not an optional line item. - **Security**: her direct parallel between dependency security review and accessibility review of themes/plugins argues for folding accessibility checks into existing supply-chain security processes rather than running them as a separate program. - **Education**: the one-hour editor training model and her critique that design schools "teach aesthetics first" both point at curriculum gaps worth addressing in both academic design programs and internal WordPress team onboarding. - **Funding models**: the "banks moving away from WordPress" claim, if verified, would be a material signal for WPOCC/FAIR-adjacent funding conversations about closing the compliance-governance gap in the WordPress ecosystem. ## 🧠 Learning Styles Assessment - **Reading level estimate**: Flesch-Kincaid Grade Level approximately 8-9, based on the talk's short, spoken-register sentences and conversational vocabulary (the transcript is a spoken talk, not written prose, so this is an approximation from sentence length and syllable density rather than a formal score run against the transcript text). #### 👀 Visual learners - Present: the talk references on-screen slides (the cost-escalation diagram, the content-churn-over-time diagram) that aren't reproduced in this transcript-derived note. - Improve: add the actual slide deck's diagrams (cost-per-phase chart, content-churn timeline, Defense in Depth layer diagram) as embedded images in any write-up of this talk. #### 🔊 Aural learners - Present: this is a recorded conference talk — the primary medium already serves aural learners directly. - Improve: a 3-5 minute audio-only recap of the three-part framework (supply chain, CI gates, Defense in Depth) would help learners who want the takeaway without the full 41-minute talk plus Q&A. #### 🗣️ Verbal learners - Present: strong use of analogy — themes/plugins as a "supply chain," coffee brewing as a dependency chain, accessibility debt as an escalating restaurant bill (€5 to €50+). - Improve: a short glossary defining EAA, BFSG, ADA, WCAG 2.2 AA, and "overlay plugin" would help verbal learners unfamiliar with the compliance jargon she otherwise explains well through analogy. #### 🧩 Kinesthetic learners - Present: the 60-second keyboard test is itself a hands-on, repeatable exercise (tab, Enter/Space, Escape, check focus visibility). - Improve: package it as a literal checklist or bookmarklet so viewers can run it immediately rather than just hearing it described. #### 🧠 Logical learners - Present: the three-risk taxonomy (legal/business/reputational) and the four-challenge breakdown (theme quality/content churn/ownership/jargon) are both clean, numbered decision structures. - Improve: a RACI-style table mapping her "accessibility lead" responsibilities against designer/developer/content-author roles would make the ownership argument more scannable. #### 🧑‍🤝‍🧑 Social learners - Present: live Q&A at the end covers overlay plugins, gendered language, design education, and worst arguments against accessibility — genuine audience interaction. - Improve: a moderated follow-up discussion thread or forum post continuing the Q&A (especially the unresolved gendered-language tension) would extend the social-learning value. #### 🧘‍♀️ Solitary learners - Present: the talk is structured as a clear personal narrative (her career path) that a solitary learner can follow linearly without needing group discussion. - Improve: add self-check reflection prompts (e.g., "does your team have a named accessibility lead? run the 60-second test on your last-installed plugin") for solo review. #### 🌿 Naturalistic learners - Present: the coffee-supply-chain analogy (beans grown, harvested, roasted, shipped) is the closest the talk comes to an ecosystem/lifecycle framing. - Improve: extend the supply-chain metaphor explicitly to WordPress's plugin ecosystem lifecycle (build, review, maintain, deprecate) for learners who respond to systems/lifecycle thinking. ## 📊 Accessibility Assessment #### Screen reader semantics - Present: the talk itself models good practice by naming concrete screen-reader failure modes (missing accessible names, unlabeled buttons) rather than speaking abstractly. - Improve: any written companion resource should map her examples to specific ARIA/semantic HTML fixes. Gap relates to **WCAG 2.2 AA 4.1.2 (Name, Role, Value)** and **1.1.1 (Non-text Content)**. #### Keyboard navigation - Present: the 60-second keyboard test she describes (tab order, Enter/Space activation, Escape to close, visible focus) is itself a direct, actionable keyboard-accessibility checklist. - Improve: pair it explicitly with **WCAG 2.2 AA 2.1.1 (Keyboard)**, **2.1.2 (No Keyboard Trap)**, and **2.4.7 (Focus Visible)** when adapting this content into a checklist artifact. #### Contrast and readability - Present: the National Rail example and the "checking contrast on real backgrounds, not just Figma" point both center contrast as a concrete, testable requirement. - Improve: cite **WCAG 2.2 AA 1.4.3 (Contrast Minimum, 4.5:1)** and **1.4.11 (Non-text Contrast)** explicitly when this content becomes a checklist, since the talk names the principle but not the criterion numbers. #### Text resizing and reflow - Present: not addressed in the talk. - Improve: a companion resource should add **WCAG 2.2 AA 1.4.4 (Resize Text)** and **1.4.10 (Reflow)** guidance, since zoom/reflow failures are a common WordPress theme issue not covered here. #### Media and captions - Present: the Netflix lawsuit example (missing closed captions) is cited as a legal-risk example, implicitly acknowledging captioning as a compliance requirement. - Improve: map explicitly to **WCAG 2.2 AA 1.2.2 (Captions, Prerecorded)** and **1.2.4 (Captions, Live)** in any derived checklist; the talk doesn't cover audio description. #### Forms and interactions - Present: the image-slider example (no pause control, no meaningful labels) covers interactive-control accessibility. - Improve: map to **WCAG 2.2 AA 2.2.2 (Pause, Stop, Hide)** for the autoplay/pause gap and **2.5.8 (Target Size Minimum)** for touch/click target sizing, neither named explicitly in the talk. #### Standards reference - The talk repeatedly invokes "WCAG" and cites the lower-secondary-reading-level content criterion by description but never by number. That criterion is **WCAG 2.2 AAA 3.1.5 (Reading Level)** — worth noting it's actually an AAA-level criterion, not AA, despite the talk's framing of content-readability requirements as standard practice. ## 🌍 DEIB Assessment #### Cultural breadth - Present: the talk draws examples from Germany (BFSG, EZB/SCA banking jargon, Leichte Sprache), the US (ADA, Domino's/Target/Netflix lawsuits), and the UK (National Rail Grayscale incident) — genuinely multi-region. - Improve: no examples from outside Europe/North America; a broader set of regional accessibility-law examples (e.g., Australia's DDA, Canada's AODA) would widen the cultural scope. #### Inclusive language - Present: the talk explicitly addresses inclusive language as a topic in the gendered-speech Q&A, and Wjertzoch names her own tension between German gender-inclusive forms and screen-reader readability. - Improve: her "clarity first, inclusion second" stance is a judgment call stated without citing any specific accessibility research on gender-neutral language and assistive-tech readability; a companion resource should cite actual usability studies rather than personal rule-of-thumb framing. #### Neurodiversity support - Present: she explicitly names people with cognitive impairments and people who are "stressed or distracted" as affected by jargon-heavy content — a direct, if brief, neurodiversity consideration. - Improve: no discussion of other neurodivergent-relevant patterns (motion sensitivity re: autoplay sliders, predictable navigation, consistent structure) despite the autoplay-slider example being a clear candidate for that framing. #### Representation - Present: named lawsuit examples span consumer brands (Domino's, Target), streaming (Netflix), and a public figure's site (Beyoncé) — a reasonably varied set of affected contexts. - Improve: all named plaintiffs/affected users in her examples are described generically as "blind users" or "viewers"; no named individual voices or first-person accounts of the affected users appear in the talk. #### Psychological safety - Present: her framing explicitly rejects shaming individual contributors — "not because anyone's evil, just because real-life deadlines...somehow always wins" — and describes the accessibility lead as "not the accessibility police." - Improve: none identified; this section of the talk models good practice. ## ✅ Logical Validity #### Strong reasoning - **Causal/mechanistic**: the "compliance can't be a plugin" argument (t=1086s) is a strong causal claim — she explains the mechanism (bolting risk management onto a system not designed for it) rather than just asserting overlays don't work, and it's consistent with her separate, well-supported rejection of overlay plugins in Q&A (they don't touch underlying code). - **Analogical**: the coffee-supply-chain analogy for theme/plugin vetting is a strong, well-mapped analogy — each link (grown, roasted, shipped) has a direct WordPress-dependency-lifecycle counterpart, and the analogy correctly predicts the fix (a lightweight gate, not a full audit). - **Evidentiary**: the legal-risk section is her strongest inductive case — she pairs a general statistic (2,019 lawsuits, UsableNet) with four named, verifiable court cases (Domino's, Target, Netflix, Beyoncé), which is a stronger inferential structure than the statistic alone. - To clarify further: naming the specific audit source for the "70% of themes fail" claim (currently just "when experts audited popular WordPress themes") would bring it up to the same evidentiary standard as the lawsuit section. #### Fallacies - No load-bearing fallacy identified. The talk is risk-and-consequence-framed by design (it's literally titled "risk management"), so it's worth checking specifically for appeal-to-fear reasoning, per the general pattern in risk-framing talks. On inspection, the fear appeals here are attached to concrete, cited mechanisms rather than vague dread: the lawsuit count comes with a named source and named defendants, the cost-escalation figure comes with an attributed source (Forrester), and the Grayscale incident is a verifiable historical event with a named responding body (RNIB). That's consequence-based argument grounded in evidence, not fallacious fear-mongering — the distinguishing test is whether the claimed consequence is sourced and specific, and here it consistently is. - One soft spot, not quite a formal fallacy: the "banks are moving away from WordPress" claim (t=1108s) is asserted with no source and functions rhetorically like an appeal to authority/trend without the authority actually being cited. Fix: either name the platforms/examples she has in mind or drop the claim, since it's the one unsupported assertion in an otherwise well-cited talk. #### Tone of voice - Conversational, self-deprecating, and story-driven — she uses first-person anecdotes ("one example that really stuck with me"), rhetorical questions ("What is supply chain management?"), and light humor (the "phase 2... is the code word for 'this will never ever happen'" line) rather than a lecturing register. The tone stays consistent through Q&A, including a willingness to say "I don't get" and ask for clarification on the gendered-speech question rather than bluffing an answer. ## 🛡️ DARVO Analysis - **Deny**: Not applicable to this source — the talk contains no accusation being denied; Wjertzoch is the presenter making claims, not a party responding to a complaint against her. - **Attack**: Not applicable to this source — no credibility attacks on any individual or accuser appear in the talk or Q&A. - **Reverse victim/offender**: Not applicable to this source — no victim/offender framing is present; the talk discusses institutional accessibility failures (National Rail, Domino's, Target, Netflix) without any party recasting itself as the victim. - No DARVO pattern is present; this is an instructional conference talk, not a response to an allegation. ## 🎯 Conclusion Wjertzoch's core claim — that WordPress accessibility failures are a risk-management problem, not a nice-to-have — is well-supported by named, sourced legal cases (Domino's, Target, Netflix, Beyoncé), a real-world reputational failure (the National Rail Grayscale incident), and an attributed cost-escalation figure (Forrester's 10x). Her proposed fix is concrete and low-cost: a 60-second keyboard test before adopting any theme or plugin, CI gates using free tools (Axe-Core, PA11Y), Defense-in-Depth pattern design from the concept phase, a one-hour editor training, and a named accessibility-lead role. The weakest point in the talk is the unsourced claim that banks are migrating off WordPress toward more compliance-native platforms — worth verifying before repeating it. Practical next step for any WordPress team: run the 60-second keyboard test on the last plugin you installed, and check whether anyone on the team currently owns accessibility the way her "accessibility lead" role describes. ## 🔄 Refactor Appendix — Accessibility Isn't Extra Work. It's Risk Management. > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. > > Konik claim-header rules: present tense, declarative, ≤10 words when > possible, searchable, unique, mirrors annotation focus if present. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) #### [H1] A 60-second keyboard test gates plugin adoption > [!quote] > Spend 60 seconds with a keyboard. **Context & use**: - [00:30:17](https://www.youtube.com/watch?v=nHsdiAXSusU&t=1817s) — the core actionable habit of the talk. - Directly reusable as a pre-install checklist item for any WordPress theme or plugin review process. **Tags**: #xref #aphorisms **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H2] 2,019 ADA lawsuits were filed against websites in H1 2025 > [!quote] > there were already 2,019 ADA lawsuits filed against websites **Context & use**: - [00:11:34](https://www.youtube.com/watch?v=nHsdiAXSusU&t=694s) — sourced to UsableNet's 2025 Midyear report, ~20% higher year-over-year. - Grounds the "legal risk" category in a checkable, dated statistic rather than a vague trend claim. **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H3] Late accessibility fixes cost up to 10 times more > [!quote] > late fixes can cost up to 10 times more **Context & use**: - [00:16:19](https://www.youtube.com/watch?v=nHsdiAXSusU&t=979s) — attributed to Forrester Research, paired with a €5/€20/€50+ design-to-launch cost escalation. - Useful as a business-case line when arguing for earlier accessibility investment. **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H4] Overlay plugins hide accessibility issues instead of fixing them > [!quote] > Real accessibility really has to be built into the product, into the code, and not pasted over it at the end. **Context & use**: - [00:42:22](https://www.youtube.com/watch?v=nHsdiAXSusU&t=2542s) — Q&A answer on overlay plugins like Eye-Able. - Directly relevant to any WordPress ecosystem discussion of overlay-based accessibility plugins, since regulators don't accept them as compliance. **Tags**: #xref #addendum **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Accessibility gates work best applied at adoption time, not audit time **Claim** (one sentence, Courtney's voice): Vetting a theme or plugin's accessibility before you adopt it is cheaper and more reliable than auditing it after it's already shipped. **Evidence pointer**: [[#H1]] — the 60-second keyboard test is a pre-adoption gate, not a post-launch audit. **Scope & conditions**: Holds for third-party themes/plugins with unknown provenance; doesn't replace ongoing CI checks or content-churn monitoring for accessibility regressions introduced after adoption. **Links** (≥1 with annotation): - [[Supply chain security review]] — because extends the same pre-adoption vetting logic from dependency security to accessibility - [[WordPress theme review criteria]] — because applies-in the Theme Review Team's audit process <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Verify the "over 70% of popular WordPress themes fail basic accessibility criteria" claim against a named, reproducible audit — no source is given in the talk. #xref - [F2] Check whether banks are actually migrating off WordPress toward compliance-native platforms, as claimed at t=1108s, or whether that's anecdotal. #xref ### → Things 3 (max 2 actions) - [ ] Run the 60-second keyboard test on the last WordPress plugin installed on a personal or client site — plugin review #things - [ ] Check whether any current WordPress project has a named accessibility-lead role per Wjertzoch's five-responsibility definition — project audit #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Accessibility Isn’t Extra Work. It’s Risk Management..md|Accessibility Isn’t Extra Work. It’s Risk Management. by Jennifer Wjertzoch]] ## Highlights - pick the one that looks nicest, and hope that it's fine; it's going to be fine, but it's usually not. That's why I suggest a little, one-minute gate at the door before you adopt any theme or plugin. Spend 60 seconds with a keyboard. Can I tap through all the interactive elements, and does the order make sense? ([View Highlight](https://read.readwise.io/read/01m21ek3jnx3sa667ean6mttkv)) - Note: The cheapest procedure in the whole batch: 60 seconds of keyboard tabbing as an adoption gate for any theme or plugin. Can you reach every interactive element, and does the order make sense? Small enough that it actually gets done. - Tags: developer-workflow, keyboard-navigation, atom/literature/h1 ## New Highlights added 2026-09-08 at 5:29 PM - and the lawsuits are real. According to the UsableNet 2025 Midyear report, in just the first 6 months of the year, there were already 2,019 ADA lawsuits filed against websites and also apps, and video content, and that's about 20% higher than the same time last year. Yes, I would say 2025 is on track to hit a new record ([View Highlight](https://read.readwise.io/read/01m21ep77zg55nspx327tgz7zn)) - Note: Sourced, unlike most numbers in this genre: UsableNet's 2025 Midyear report, 2,019 ADA suits in H1 2025, up about 20% year over year. Worth checking against UsableNet directly before repeating it anywhere public. - Tags: risk-management, legal-compliance, atom/literature/h2