# Creating a WCAG-Compliant WordPress Website in 2026 — Ben P (Yellow Peach) ## 🗂️ Triage — annotated highlights surfaced > [!note]- Cross Reference > - **Automated scanners catch roughly a third of WCAG issues** — the load-bearing reason manual/assistive-tech testing has to be budgeted, not skipped. #xref > - **Overlay plugins have become lawsuit sources, not shields** — one-line client rebuttal when a prospect proposes an overlay as a compliance shortcut. #xref > - **Built-in beats bolted-on** — accessibility holds up only when it's in the markup from the start. #xref ## 🧭 Bib capsule Ben P, "Creating a WCAG-Compliant WordPress Website in 2026," Yellow Peach, 2026 — https://yellowpeach.co.uk/wcag-compliant-wordpress-website/ ## 🧠 Author's thesis (Adler Q1+Q2) A UK WordPress agency argues that WCAG 2.2 Level AA has become a baseline requirement in 2026, forced by the European Accessibility Act, UK Equality Act/PSBAR exposure, and ongoing US ADA lawsuit volume. In detail: it walks through POUR and the three conformance levels, prescribes building accessibility in from the start (semantic markup over page-builder div soup, correct heading structure and form labels, WCAG contrast minimums, keyboard operability, alt text/captions), separates automated scanning from manual/assistive-tech testing, and argues overlay plugins are a liability rather than a fix — closing with a soft pitch for the agency's audit/rebuild services. The technical guidance is sound; the legal/statistical claims are unsourced and should be treated as directional. ## 🧩 Key arguments - Regulation (EAA applicable since June 2025, UK PSBAR statutory obligation, US ADA case law) is the forcing function pushing WCAG 2.2 AA from nice-to-have to baseline. - Real accessibility comes from semantic build practice — clean markup, one H1, real `nav`/`main`/`button` elements, labeled inputs, 4.5:1 / 3:1 contrast, full keyboard operability — not from scripts layered on afterward. - Overlay/widget plugins fail to fix underlying issues, can interfere with genuine assistive tech, and have become a documented source of lawsuits. ## 🗒️ Notes — Literature atoms ### Automated scanners catch roughly a third of WCAG issues > [!quote] > "Automated tools generally catch around 30-40% of WCAG issues" - **Where**: Auditing an Existing WordPress Site - **Why**: Justifies budgeting manual + screen-reader testing time in any audit rather than trusting a Lighthouse run. (Unsourced in the article — cross-check against WebAIM before reusing.) ### Overlay plugins have become lawsuit sources, not shields > [!quote] > "they've become a documented source of lawsuits rather than protection" - **Where**: Why WordPress Plugin Overlays aren't the Answer - **Why**: Matches the accessibility-advocacy consensus (overlay fact-sheet campaign); a ready client rebuttal to the overlay-as-quick-fix pitch. ### WCAG 2.2 AA sets 4.5:1 contrast for normal text > [!quote] > "WCAG 2.2 AA requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text" - **Where**: Colour contrast and visual design - **Why**: A concrete, checkable pass/fail audit threshold — distinct from the article's softer unsourced claims. ## 🔖 Permanent candidates - Accessibility belongs in the build, not bolted on after — 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. (Scope: structural/semantic issues; content-level fixes like alt text can be added post-hoc.) ## Links - [[Open Source Governance MOC]] — home MOC; WordPress accessibility practice is an ecosystem-governance concern (core accessibility team priorities, agency norms) with no dedicated a11y MOC. - [[Lit · Accessibility work shapes product and culture]] — connects the "build-it-in" argument to how accessibility investment reshapes product and team culture, not just compliance. - [[State of Accessibility in WordPress 6.3 Gutenberg]] — grounds the generic "semantic markup over div soup" advice in the specific state of WordPress block-editor accessibility. ## ✅ Processing checklist - [x] Claim atoms carried from deep-read analysis - [ ] Permanent candidates reviewed for promotion - [ ] Version History Diff check