Creating a WCAG-Compliant WordPress Website in 2026  🔗 **Source:** [Creating a WCAG-Compliant WordPress Website in 2026](https://yellowpeach.co.uk/wcag-compliant-wordpress-website/) > [!note]+ Document Notes > tags: [wcag-compliance, wordpress-accessibility, web-accessibility-law, accessibility-overlays, semantic-html] > author: Ben P > source: Yellow Peach > reference: https://yellowpeach.co.uk/wcag-compliant-wordpress-website/ > date created: 2026-07-14 00:00 > > # 🏷️ Title: Creating a WCAG-Compliant WordPress Website in 2026 > <!-- 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) ## 📝 Summary - **What happened**: Yellow Peach, a UK WordPress agency, publishes a promotional/educational article arguing that WCAG 2.2 Level AA compliance has become a baseline requirement for WordPress sites in 2026, driven by the European Accessibility Act, UK Equality Act exposure, and ongoing US ADA lawsuit volume. It walks through what WCAG compliance means, how to build accessibility into a WordPress site from scratch (theme choice, semantic HTML, contrast, keyboard nav, alt text), how to audit an existing site, why overlay plugins are a liability rather than a fix, and common accessibility myths — closing with a soft pitch for the agency's audit/rebuild services. - **Why it matters**: This is a compact, current (2026) restatement of the WordPress accessibility consensus that has hardened over the last few years — overlays are dead, semantic markup and manual testing are the actual work, and regulation (EAA, UK PSBAR, ADA case law) is the forcing function rather than pure ethics. It's useful as a dated snapshot of "what a WordPress agency tells prospective clients accessibility now costs/requires." - **Key stakeholders**: WordPress site owners and buyers (SMBs, ecommerce operators, public sector via UK PSBAR), WordPress agencies/developers (Yellow Peach as author and vendor), disabled users/screen reader and keyboard users, regulators (W3C/WCAG working group, EU Commission for EAA, UK equality bodies), and the ADA plaintiff's bar in the US. - **Risks and tradeoffs**: The article is marketing content with a sales CTA, so its accessibility claims are undercut by an absence of citations — most of the load-bearing statistics ("30-40% of WCAG issues" caught by automated tools, "43% of all websites" run WordPress, EAA enforcement timeline) are stated as fact with no linked source. It also doesn't address AAA-track requirements, doesn't mention overlay vendors by name (defensible legally, but weakens the "documented source of lawsuits" claim), and gives cost guidance ("depends on starting point") that is functionally non-committal. - **Bottom line**: The substantive accessibility guidance (semantic HTML over page-builder div soup, 4.5:1/3:1 contrast minimums, real keyboard/screen-reader testing, rejecting overlay plugins) matches current WCAG 2.2 AA and WordPress accessibility community consensus and is directly applicable to Courtney's own WordPress accessibility work; the regulatory/legal framing should be treated as directional context rather than legal advice, since none of the legal claims are sourced. ## 📖 Main Content - **WCAG structure (POUR + three levels)**: The article correctly frames WCAG under the W3C's four principles — Perceivable, Operable, Understandable, Robust — and the three conformance levels (A minimum, AA the common legislative/practical target, AAA selective-only). This is accurate and matches the WCAG 2.2 spec itself; the "AA as baseline, AAA impractical site-wide" framing is standard advice repeated across the accessibility field. - **The 2026 regulatory case**: Three legal threads are invoked — the EU's European Accessibility Act (applicable since June 2025, enforcement described as "underway" in 2026), the UK's Equality Act 2010 plus the Public Sector Bodies Accessibility Regulations (statutory WCAG 2.2 AA obligation for public sector, reasonable-adjustment exposure for private business), and continuing ADA-driven lawsuits/demand letters in the US. These are real legal mechanisms, but the article states them without citing enforcement actions, case counts, or official sources — so the *direction* (increasing exposure) is credible, the *specifics* (exact enforcement status, lawsuit volume trend) are unverified from this source alone. - **Build-in-from-the-start guidance**: The technical section is the strongest part of the piece and reads as genuine practitioner advice rather than filler: avoid page-builder-generated markup because it tends to be deeply nested and non-semantic; use one H1 with logically nested H2/H3; use real `nav`/`main`/`button`/`article` elements instead of styled `div`s; label every form input programmatically; hit 4.5:1 contrast for normal text and 3:1 for large text (this is the correct WCAG 2.2 AA numeric threshold, 1.4.3); ensure full keyboard operability with visible focus, sensible tab order, and no keyboard traps (2.1.1/2.1.2/2.4.7); alt text on meaningful images, empty alt on decorative images, captions on video, transcripts for audio. - **Auditing**: Correctly separates automated tools (WAVE, axe DevTools, Lighthouse) from manual/assistive-tech testing (keyboard-only navigation, NVDA/VoiceOver, 200% zoom, form/interaction review), and cites "around 30-40% of WCAG issues" as the ceiling for automated detection — a figure that is directionally consistent with commonly cited industry estimates (numbers in this range circulate widely in accessibility literature, though the article doesn't attribute a specific study). - **Overlay plugins**: The strongest normative claim in the article — that overlay/widget plugins that inject accessibility scripts have become "a documented source of lawsuits rather than protection" and "frequently fail to fix underlying issues and sometimes interfere with genuine assistive technology." This matches the broader disability-advocacy and accessibility-professional consensus (the "overlay fact sheet" campaign led by accessibility advocates has documented overlay-related lawsuits and interference issues for several years), though again no specific case or source is named here. - **Myths section**: Rebuts four common objections — "accessibility only helps a few users" (counters with situational/temporary benefit examples: captions in noise, focus states for power users, contrast for outdoor mobile use), "a plugin can make us compliant" (restates the overlay critique), "accessible means ugly" (asserts constraints improve design, a claim aligned with mainstream accessible-design practice but asserted rather than demonstrated), and "we'll deal with it if someone complains" (argues reactive posture is costlier than proactive work, again without cost data). - **Uncertainties/contested claims**: No named sources, studies, or case law throughout. "43% of all websites" run WordPress is a commonly cited figure (roughly consistent with W3Techs data trends, though the exact number fluctuates release to release and isn't sourced here). The claim that EAA "enforcement" is specifically "underway in 2026" is asserted without detail on what enforcement activity has actually occurred. Cost guidance is intentionally vague ("depends on starting point"). ### 🗒️ Notes - Article is not a transcript and contains no timestamps; dense notes only, no timestamp subheadings per template rule. - Yellow Peach's positioning: builds "custom, semantic WordPress themes" rather than using page builders — this is both a technical claim and a sales differentiator, since page-builder criticism doubles as a pitch against a competing build approach. - The FAQ section functions as schema-markup bait (structured Q&A format) as much as reader aid — a common SEO pattern for "answer engine" visibility, consistent with the article's likely purpose of ranking for WCAG/WordPress accessibility queries. - No mention of the EN 301 549 standard, which is the actual technical standard EAA and many EU/UK public-sector regulations point to (it incorporates WCAG but adds non-web requirements) — an omission worth noting for anyone using this article as a compliance reference. - No mention of automated-tool specifics like `axe-core` rule coverage, or of WordPress-specific accessibility tools (e.g., WP Accessibility plugin, a11y-focused themes like Twenty Twenty-Five's baseline, or the WordPress core accessibility team's handbook) — the article stays at a generic, tool-agnostic level throughout. - No discussion of ARIA beyond one line ("interactive elements lacking proper ARIA or semantic markup") — no guidance on when ARIA helps vs. when "no ARIA is better than bad ARIA" (a core accessibility principle the article doesn't state despite implying it). ## 📚 References - [WCAG 2.2 (W3C)](https://www.w3.org/TR/WCAG22/) — the standard referenced throughout; not linked in the source article. - [European Accessibility Act — European Commission](https://ec.europa.eu/social/main.jsp?catId=1202) — referenced by name, not linked in source. - [Equality Act 2010 (UK legislation.gov.uk)](https://www.legislation.gov.uk/ukpga/2010/15/contents) — referenced by name, not linked in source. - [Public Sector Bodies Accessibility Regulations 2018](https://www.legislation.gov.uk/uksi/2018/952/contents/made) — referenced by name, not linked in source. - [WebAIM: The WebAIM Million / overlay research](https://webaim.org/projects/million/) — not cited in source, but the closest primary-research analog to the "30-40% caught by automated tools" and overlay-failure claims. - [WAVE, axe DevTools, Google Lighthouse] — named as automated testing tools; no links provided in source. - [NVDA, VoiceOver] — named as screen readers for manual testing; no links provided in source. ## 🗣️ Paraphrase - Yellow Peach argues that in 2026, meeting WCAG 2.2 Level AA on a WordPress site stopped being a nice-to-have and became table stakes, because the EU's accessibility law is now enforceable, the UK's equality law already covers websites (with an extra statutory layer for public sector), and American ADA lawsuits over inaccessible sites keep piling up — and WordPress, running a huge share of the web, catches a lot of that exposure. - Its practical advice is: build accessibility in from day one — pick or build a theme with clean semantic markup instead of page-builder div soup, get heading structure and form labels right, hit the WCAG contrast minimums, make everything keyboard-operable with visible focus states, and handle alt text and media captions properly — then audit with a mix of automated scanners (which only catch a third to two-fifths of real issues) and actual manual/screen-reader testing, and whatever you do, don't buy an accessibility overlay plugin and call it done, because those have turned into their own source of lawsuits. ## 📰 Newsletter Accessibility compliance keeps getting less optional for WordPress sites — Yellow Peach's 2026 rundown ties it to real regulatory pressure (EU Accessibility Act now applicable, UK Equality Act/PSBAR obligations, and the steady drumbeat of US ADA site lawsuits) and lands on the same conclusion the WordPress accessibility community has been pushing for years: build it into the theme and markup, don't paper over it with an overlay plugin. Worth a skim for the WCAG 2.2 AA contrast numbers (4.5:1 normal text, 3:1 large text) and the reminder that automated scanners like WAVE/axe/Lighthouse only catch roughly 30-40% of real issues — manual and screen-reader testing (NVDA, VoiceOver) still carries the rest. If you're auditing a WordPress site this quarter, the myths section is a handy one-pager to forward to a client who thinks a plugin will make the problem go away. - [Article: Creating a WCAG-Compliant WordPress Website in 2026](https://yellowpeach.co.uk/wcag-compliant-wordpress-website/) - [WCAG 2.2 spec](https://www.w3.org/TR/WCAG22/) ## ✅ Action Items #### DevRel - Not applicable to this source — the article is agency marketing/educational content aimed at site owners, not a developer-relations program with talks, SDKs, or funnels. #### OSPO - Not applicable to this source — no open-source governance, licensing, or SBOM content appears in the article. #### Community - Not applicable to this source — no maintainer/contributor/sponsor community structure is discussed; the article addresses site owners and prospective agency clients. #### WordPress - **Accessibility**: Directly relevant — the article's core content maps onto WordPress core accessibility team priorities: theme markup semantics, heading hierarchy, contrast, keyboard operability, and the overlay-plugin problem the core team and Make WordPress Accessibility group have flagged for years. Action: use this article's plain-language framing as a client-facing accessibility explainer, and cross-check its claims against the Make WordPress Accessibility handbook before reusing them in client materials. - **Documentation**: The FAQ section is reusable as a client-education snippet (WCAG level guidance, overlay-plugin caution, audit cost framing) but needs primary-source citations added before reuse in any authoritative context. - **Support**: The "we'll deal with it if someone complains" myth rebuttal is a useful line for support/sales conversations pushing back on reactive accessibility postures. - Other WordPress subteams (Core, Mobile, Playground, Training, Marketing, Design, Photos, TV, Polyglots, Meta, CLI, Hosting, Tide, Openverse, Themes, Plugins) — not applicable; the article doesn't touch these areas. #### The WPCC - Not applicable to this source — no fellowship, grant, or governance-artifact content appears. ### FAIR - Not applicable to this source — no federated/independent infrastructure content appears; the article is squarely about WordPress front-end accessibility practice. ## 🧪 Hypotheses 1. WordPress sites built with heavy page-builder plugins produce measurably more WCAG 2.2 AA failures (heading structure, ARIA misuse, div-based "buttons") than sites built with hand-coded semantic themes. 2. Automated accessibility scanners (WAVE, axe, Lighthouse) catch a minority (roughly 30-40%) of true WCAG failures on a representative sample of WordPress sites, with the remainder requiring manual/assistive-tech testing to surface. 3. WordPress sites running a popular accessibility overlay plugin have a higher, not lower, rate of ADA demand letters/lawsuits than comparable sites with no overlay, once site traffic and sector are controlled for. 4. Public-sector WordPress sites in the UK show measurably higher WCAG 2.2 AA conformance than private-sector WordPress sites of comparable size, consistent with PSBAR's statutory (vs. merely reputational) obligation. 5. Contrast-ratio and keyboard-navigation fixes made for accessibility compliance correlate with improved conversion or engagement metrics on WordPress ecommerce sites (testing the "accessibility helps everyone" usability claim). ### 📊 Methodology - For H1: audit a stratified sample of WordPress sites (e.g., 50 page-builder-built vs. 50 hand-coded-theme sites, matched by traffic/sector) using a fixed WCAG 2.2 AA checklist; compare failure counts and failure types. - For H2: run WAVE/axe/Lighthouse against a sample of sites that have also undergone full manual + screen-reader audits; compare automated-flagged issue counts to the manual audit's total confirmed issue count to derive an actual catch-rate percentage, replacing the article's unsourced "30-40%" estimate. - For H3: cross-reference a list of known overlay-plugin-using WordPress sites (via plugin detection scanning) against ADA lawsuit/demand-letter databases (e.g., UsableNet's annual report, Seyfarth Shaw's ADA Title III tracker) over a multi-year window. - For H4: sample UK public-sector WordPress sites (gov.uk-adjacent, council, NHS trust sites) vs. UK private-sector WordPress sites of similar traffic tier; run identical automated + manual WCAG 2.2 AA audits and compare pass rates. - For H5: A/B or before/after analysis on WordPress ecommerce sites that shipped a documented accessibility remediation (contrast, keyboard nav) — compare conversion rate, bounce rate, and average session duration pre/post change, controlling for seasonality. ### ❓ Questions - What specific enforcement actions (fines, injunctions, formal notices) have occurred under the European Accessibility Act since it became applicable in June 2025, and how many involve WordPress-built sites specifically? - Is the "30-40%" automated-detection figure attributable to a specific study (e.g., WebAIM, Deque, or a peer-reviewed source), or is it a rounded industry rule of thumb that's been repeated without re-verification? - Does Yellow Peach's own portfolio of "custom, semantic WordPress themes" undergo the same manual + assistive-tech audit process it recommends to prospective clients, and is that audit published anywhere? - How does WCAG 2.2's Level AA numeric contrast requirement (4.5:1 / 3:1) interact with brand color palettes in practice — how often do agencies have to push back on a client's brand colors to hit compliance, and how is that conversation handled? - What does "EN 301 549" add on top of WCAG 2.2 for EAA compliance specifically, and does the article's WCAG-only framing understate what EU compliance actually requires? ### 🔮 Future Research - A WordPress-specific longitudinal study tracking ADA demand-letter volume against detected use of accessibility overlay plugins, to test whether overlays correlate with more or fewer legal actions over time (directly testable given plugin-detection tooling and public lawsuit trackers). - A comparative audit of WordPress core/default themes (Twenty Twenty-Three through Twenty Twenty-Six) against third-party page-builder themes for baseline WCAG 2.2 AA conformance, to quantify the "page builder bloat" claim rather than assert it. - Research into whether EAA enforcement mechanisms (which vary by EU member state, since it's a directive requiring national transposition) are actually operative in 2026 as stated, or still in a grace/build-out period in most jurisdictions. ### 💡 Implications - **Practice**: Agencies and in-house WordPress teams should treat semantic markup and manual/assistive-tech testing as core build steps, not a post-launch add-on — matching Courtney's own `wordpress-accessibility` skill approach of automated + manual audit combined. - **Policy**: The EAA's June 2025 applicability date plus UK PSBAR obligations mean any WordPress site serving EU or UK public-sector-adjacent audiences should treat WCAG 2.2 AA as a compliance floor, not a stretch goal, regardless of this article's marketing framing. - **Security**: Overlay plugins are a double liability — they don't fix underlying accessibility problems and add another third-party script with its own maintenance/security surface on the site. - **Education**: The myths section is a reusable client-education tool, but should be paired with sourced statistics before being repeated as authoritative in Courtney's own client-facing content (per the site's no-marketing-speak-in-technical-docs standard). - **Funding models**: Framing accessibility as "built in from the start costs little extra" vs. "retrofitting varies widely" is a useful sales argument for agencies to justify accessibility line items in new-build quotes rather than treating them as optional add-ons. ## 🧠 Learning Styles Assessment - **Reading level estimate**: Flesch-Kincaid Grade approximately 11-12 (professional/marketing blog register — moderate sentence length, some jargon like "POUR," "ARIA," "conformance level" used without full definition on first use). #### 👀 Visual learners - Present: heading-based section structure, a bulleted contrast-ratio callout, bolded key terms (Level A/AA/AAA). - Improve: no diagrams, screenshots of actual contrast failures, or before/after markup comparisons anywhere in the piece — a side-by-side of "page-builder div soup" vs. "semantic HTML" would do more than the prose description. #### 🔊 Aural learners - Present: none — no audio/podcast version or narration referenced. - Improve: a 2-3 minute audio summary of the "why 2026" regulatory section would suit readers evaluating compliance urgency while multitasking. #### 🗣️ Verbal learners - Present: plain-language myth-busting section with conversational rebuttals ("this persistent myth is false"). - Improve: no glossary for terms like "overlay plugin," "ARIA," "POUR," or "conformance level" — a reader unfamiliar with accessibility jargon has to infer meaning from context. #### 🧩 Kinesthetic learners - Present: a loosely step-by-step "build it in from the ground up" structure (theme, markup, contrast, keyboard, media). - Improve: no actual checklist, code snippet, or sandbox link a developer could act on directly — every point is asserted, none demonstrated. #### 🧠 Logical learners - Present: the three-level (A/AA/AAA) and POUR framework give some structural logic. - Improve: no table mapping WCAG success criteria to the article's claims (e.g., contrast → 1.4.3, keyboard → 2.1.1) — a criteria-reference table would strengthen the logical scaffolding considerably. #### 🧑‍🤝‍🧑 Social learners - Present: none — no forum, comment thread, or discussion prompt. - Improve: a linked case study or client testimonial about a real remediation project would give social learners a concrete anchor. #### 🧘‍♀️ Solitary learners - Present: the FAQ section supports self-paced, self-directed reading. - Improve: no self-check quiz or "audit your own site in 10 minutes" worksheet, despite gesturing at self-audit via free tools. #### 🌿 Naturalistic learners - Present: none — no sustainability or ecosystem-impact framing. - Improve: not a natural fit for this topic; no improvement needed. ## 📊 Accessibility Assessment _(Meta note: this assessment evaluates the article's own web page as a reading experience, distinct from the article's subject matter about WCAG compliance.)_ #### Screen reader semantics - Present: the fetched content shows clear heading hierarchy (H1 title, H2 sections, H3 sub-points) consistent with the article's own advice. - Improve: cannot verify actual landmark/ARIA implementation or alt text on any images from fetched text content alone — would need a live DOM/axe scan of yellowpeach.co.uk itself to confirm the site practices what the article preaches. #### Keyboard navigation - Present: not verifiable from text content alone. - Improve: recommend running a keyboard-only pass and axe DevTools scan on the live page before citing it as an accessibility authority in any client-facing material — there is some irony risk if the source site itself has accessibility gaps. #### Contrast and readability - Present: not verifiable from fetched text; typical blog article structure suggests standard body text/heading sizing. - Improve: verify actual rendered contrast ratios on yellowpeach.co.uk against its own stated 4.5:1/3:1 thresholds. #### Text resizing and reflow - Present: not verifiable from text content. - Improve: standard 200% zoom test recommended given the article itself cites this as a manual-testing method. #### Media and captions - Present: no video/audio content detected in the fetched article. - Improve: not applicable — the article is text-only. #### Forms and interactions - Present: a contact/CTA likely exists ("Need Help Making Your WordPress Site WCAG-Compliant?") but form fields aren't captured in the fetched text. - Improve: verify any contact form has properly linked labels, per the article's own "Proper Form Labelling" guidance. #### Standards reference - Maps to WCAG 2.2 AA success criteria 1.3.1 (Info and Relationships/headings), 1.4.3 (Contrast Minimum), 2.1.1/2.1.2 (Keyboard/No Keyboard Trap), 2.4.7 (Focus Visible), 1.1.1 (Non-text Content/alt text), 1.2.2/1.2.1 (Captions/transcripts). ## 🌍 DEIB Assessment #### Cultural breadth - Present: covers three jurisdictions (EU, UK, US) giving some geographic breadth to the regulatory argument. - Improve: entirely Anglo/EU-centric — no mention of accessibility law or WordPress accessibility practice in other major WordPress markets (India, Brazil, Indonesia), despite WordPress's global usage footprint being central to the article's own "43% of websites" claim. #### Inclusive language - Present: consistently uses "disabled users," "users with low vision," "colour blindness" — direct, respectful, non-euphemistic terminology throughout. - Improve: no explicit mention of cognitive, neurological, or situational disabilities beyond low vision/color blindness/keyboard use — WCAG's broader disability coverage (cognitive load, seizure triggers, motor impairment beyond keyboard use) is underrepresented. #### Neurodiversity support - Present: consistent heading structure and chunked bullet lists throughout aid scanability. - Improve: no mention of cognitive accessibility criteria (WCAG 2.2 adds several, e.g., 3.3.7 Redundant Entry, 2.4.11 Focus Not Obscured) despite the article explicitly targeting "2.2" in its framing — a notable content gap given the version number in the title. #### Representation - Present: references generic "disabled users," "users with low vision," "outdoor mobile users" without stereotyping. - Improve: no direct quotes or case examples from actual disabled users or accessibility professionals — all guidance is agency-voiced, not community-sourced. #### Psychological safety - Present: non-alarmist tone in the myths section; frames proactive accessibility as opportunity rather than shaming non-compliant businesses. - Improve: the legal-risk framing throughout (lawsuits, demand letters, reputational risk) could read as fear-based sales pressure rather than a rights-based framing centering disabled users' actual experience — a subtle but consistent rhetorical choice worth naming. ## ✅ Logical Validity #### Strong reasoning - The build-in-from-the-start section uses sound causal reasoning: bloated/non-semantic markup → screen readers and keyboard nav struggle → users are excluded. Each claim (heading hierarchy, semantic elements, form labels) ties to a specific, checkable mechanism, making this the article's strongest reasoning block. - The "automated tools catch 30-40%" framing followed by "manual testing needed" is valid inductive reasoning from a stated (if unsourced) premise to a sound practical conclusion — even if the premise itself needs a citation, the inference from premise to recommendation is logically sound. #### Fallacies - **Appeal to authority without citation** (throughout the regulatory section): claims like "ADA lawsuits... continued climbing year after year" and "WordPress powers over 43% of all websites" are stated as settled fact with no source, functioning as an implicit appeal to the reader's assumed trust in the agency's expertise. Fix: link to UsableNet/Seyfarth Shaw ADA litigation reports and W3Techs CMS market-share data respectively. - **Hasty generalization** ("Yellow Peach avoids relying on bloated page builders... for full control"): implies all page-builder output is inherently inaccessible and all custom themes are accessible by virtue of being custom — but a poorly coded custom theme can be just as inaccessible as a poorly configured page-builder site, and some page builders (e.g., ones built on block-based semantic markup) have improved considerably. The claim conflates "common failure mode" with "inherent property." - **False dichotomy** (implicit in the "overlays vs. real accessibility" framing): presents the choice as overlay-plugin vs. built-in accessibility, without acknowledging that some assistive browser extensions or genuinely well-scoped accessibility-enhancement plugins (distinct from the "overlay" category specifically criticized by advocates) can play a legitimate supporting role. #### Tone of voice - Confident, advisory, mildly sales-oriented — e.g., "Real accessibility comes from how a site is built, not scripts layered afterwards" reads as both a technical claim and a value proposition. The FAQ section shifts to a plainer, more neutral explanatory register. The closing CTA ("Need Help Making Your WordPress Site WCAG-Compliant?") makes the commercial intent explicit and should be read as the interpretive frame for the whole piece. ## 🛡️ DARVO Analysis Not applicable to this source — DARVO (Deny, Attack, Reverse Victim and Offender) is a framework for analyzing a specific person or institution's response to an accusation of wrongdoing. This article contains no accusation-and-response dynamic: it is prospective advocacy/marketing content advising readers on a compliance practice, not a defense against a claim made against Yellow Peach or any named party. The closest analog — the article's implicit case against overlay-plugin vendors — is a critique the article is making, not defending against, so it doesn't fit the DARVO pattern either. ## 🎯 Conclusion - **Bottom line**: The article correctly summarizes the current, hardened WordPress-accessibility consensus — build semantic markup in from the start, hit WCAG 2.2 AA's numeric thresholds, test with both automated tools and real assistive technology, and treat overlay plugins as a liability rather than a shortcut — but its legal/statistical claims are unsourced and should be treated as directional marketing framing rather than a citable compliance reference. - **Practical next steps for readers**: Verify the EAA/PSBAR/ADA specifics against primary legal sources before using them in client-facing compliance advice; use the article's technical checklist (heading hierarchy, semantic elements, form labels, 4.5:1/3:1 contrast, keyboard operability, alt text/captions) as a solid starting audit checklist; run both automated (WAVE/axe/Lighthouse) and manual (keyboard-only, NVDA/VoiceOver, 200% zoom) passes on any WordPress site in question; and if evaluating Yellow Peach or any similarly-positioned agency, ask to see their own site's accessibility audit results as a credibility check. ## 🔄 Refactor Appendix — Creating a WCAG-Compliant WordPress Website in 2026 > 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] Automated scanners catch roughly a third of WCAG issues > [!quote] (no Readwise ID — analysis produced outside the Reader save flow) > "Automated tools generally catch around 30-40% of WCAG issues" **Context & use**: - Auditing an Existing WordPress Site section. - Load-bearing claim for the article's core argument that manual/assistive-tech testing is mandatory; directly reusable in Courtney's `wordpress-accessibility` client audits to justify budgeting manual testing time, not just a Lighthouse run. **Tags**: #xref **Highlight**: not applicable — no Reader save performed in this task <!-- atomicity: 1 idea ✓ --> #### [H2] Overlay plugins have become lawsuit sources, not shields > [!quote] (no Readwise ID — analysis produced outside the Reader save flow) > "they've become a documented source of lawsuits rather than protection" **Context & use**: - Why WordPress plugin Overlays aren't the Answer section. - Matches the broader accessibility-advocacy consensus (the overlay fact-sheet campaign); useful as a one-line client rebuttal when a prospect proposes an overlay plugin as a quick compliance fix. **Tags**: #xref **Highlight**: not applicable — no Reader save performed in this task <!-- atomicity: 1 idea ✓ --> #### [H3] WCAG 2.2 AA sets 4.5:1 contrast for normal text > [!quote] (no Readwise ID — analysis produced outside the Reader save flow) > "WCAG 2.2 AA requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text" **Context & use**: - Colour contrast and visual design section. - Concrete, checkable numeric threshold — directly reusable as an audit pass/fail criterion, distinct from the article's softer, unsourced claims elsewhere. **Tags**: #xref **Highlight**: not applicable — no Reader save performed in this task <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Accessibility fixes belong in the build, not bolted on after **Claim** (one sentence, Courtney's voice): Accessibility compliance holds up only when it's built into a site's markup and structure from the start, because scripts and plugins layered on afterward can't fix a foundation that was never semantic. **Evidence pointer**: [[#H2]] **Scope & conditions**: Holds for structural/semantic issues (headings, landmarks, keyboard operability, form labels); doesn't fully extend to content-level fixes (alt text, captions) which genuinely can be added post-hoc without a rebuild. **Links** (≥1 with annotation): - [[wordpress-accessibility skill]] — because applies-in every WordPress accessibility audit or rebuild Courtney runs - [[Overlay-plugin critique]] — because evidence-for the "built-in beats bolted-on" claim <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Verify whether yellowpeach.co.uk's own site practices the semantic-markup/contrast/keyboard standards it advises clients to meet — quick axe DevTools + keyboard pass would confirm or complicate the article's credibility. #xref - [F2] Look up EN 301 549 and how it extends WCAG for EAA compliance — the article never mentions it despite EAA being one of its three legal pillars. #xref ### → Things 3 (max 2 actions) - [ ] Cross-check the article's "30-40% automated detection" and "43% of websites run WordPress" figures against WebAIM/W3Techs primary sources before reusing either stat in client-facing accessibility materials — content #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Creating a WCAG-Compliant WordPress Website in 2026.md|Creating a WCAG-Compliant WordPress Website in 2026 by yellowpeach.co.uk]] ## Highlights - WCAG 2.2 AA requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text. This isn’t just a compliance checkbox, poor contrast makes text genuinely difficult to read for users with low vision, colour blindness, or simply anyone using their phone outdoors in bright sunlight. ([View Highlight](https://read.readwise.io/read/01kxh9exmtx5kyk1t9vy0kyhje)) - Tags: atom/literature/h3 - Automated tools generally catch around 30-40% of WCAG issues. That’s a meaningful head start, but it also means the majority of real-world accessibility barriers require manual review to identify. ([View Highlight](https://read.readwise.io/read/01kxh9eteg4qapkha3q0gwx1g7)) - Tags: atom/literature/h1 - A word of caution here. So-called “accessibility overlay” plugins, which claim to make your site WCAG-compliant by injecting a script, have become widespread on WordPress. They’re marketed as a quick fix, but they’ve also become a well-documented source of lawsuits rather than protection from them, because they frequently fail to fix the underlying issues and sometimes actively interfere with genuine assistive technology. ([View Highlight](https://read.readwise.io/read/01kxh9ewaxdtycyrqw56n0sacw)) - Tags: atom/literature/h2 - Real accessibility comes from how a site is built, not from a script layered on top of it after the fact. If your current WordPress site has accessibility issues, they’re best addressed through proper development work rather than a plugin promising a shortcut. ([View Highlight](https://read.readwise.io/read/01kxh9f17ft0zaw0sr49q0m9gp)) - Tags: atom/literature/h4