WordPress accessibility statement: what to include
A WordPress site is rarely just WordPress core — it's core plus a theme (often heavily customized), plus a page builder, plus a handful of plugins for forms, booking, chat, or e-commerce. Your accessibility statement needs to account for all of it. Below is the structure, the plugin-stack gap most site owners miss, and a worked example. No signup required.
Want a statement built for you instead of from scratch? Try the free accessibility statement generator — it produces a draft you can adapt to your site in a couple of minutes.
Why WordPress sites need a statement that names their stack
WordPress's flexibility is also its accessibility risk. Your theme may be a third-party product you've customized with a page builder (Elementor, Divi, Beaver Builder, or similar), and your site likely runs several plugins that each render their own markup — a contact form plugin, a booking widget, a live chat bubble, maybe WooCommerce for checkout. Every one of those pieces sits outside the accessibility of "WordPress core" itself, and each can introduce its own barriers: a form plugin with unlabeled fields, a page builder that outputs non-semantic divs instead of real headings, a chat widget with no keyboard focus trap protection.
A statement that only says "built on WordPress" and stops there is incomplete. Naming your theme and plugin dependencies — without pretending you personally audited each plugin's source code — is both more honest and more useful to a visitor who hits a specific barrier.
The statement structure, free
A complete accessibility statement covers six parts. For a WordPress site, three of them need stack-specific language:
- Commitment statement — who you are, what standard you target (WCAG 2.2 Level AA is the current, defensible default — see below).
- Ongoing effort framing — accessibility as a continuous program, not a one-time claim, with a stated review cadence (quarterly is recommended for a site where plugins update independently of your own release cycle).
- Feedback and accommodation channel — a monitored email, ideally also a phone line, plus what happens if a visitor needs an alternative way to complete a task on your site.
- Third-party content — the WordPress-specific section. This is where you name what you don't fully control: your theme, any page builder, and installed plugins (forms, booking, chat, e-commerce). State plainly that you select themes and plugins with accessibility in mind where practical, and that you'll work with your feedback channel to address issues.
- Technical specifications — the technologies your site relies on (HTML, WAI-ARIA, CSS, JavaScript) and that accessibility can be affected by a visitor's own browser or assistive technology.
- Scope — which domain(s) the statement covers, and what's explicitly excluded (a separate documentation subdomain, a members-only area, etc.).
Worked example: the third-party content section
"Our site may include or link to content, tools, or interactive elements provided by third parties — including our WordPress theme, page-builder components, and installed plugins for forms, booking, and chat. We do not control the accessibility of third-party code and cannot guarantee its conformance with WCAG 2.2 Level AA. We select themes and plugins with accessibility in mind where practical, and will work with vendors to address issues raised through our feedback channel."
That paragraph does real work: it's honest about what's outside your direct control, without using that as an excuse to avoid the topic — which is exactly the posture courts and the DOJ favor over a blanket, unqualified "fully compliant" claim.
Which standard to commit to
ADA Title III doesn't have one codified technical standard for websites the way the EU's European Accessibility Act has EN 301 549 — the DOJ has stated Title III applies to websites of "public accommodations" but hasn't finalized website-specific regulations. In practice, U.S. courts and DOJ settlement agreements most commonly reference WCAG 2.0 or 2.1 Level AA as the de facto benchmark. Committing to WCAG 2.2 Level AA — the current version — meets and exceeds that common practice.
What the full Core Kit statement template adds
The structure above is real and usable — but a statement that's about to go live on your site should come from a complete, legal-reviewed template, not assembled section by section. The AccessibleDocs Core Kit includes the full US/ADA accessibility statement template with:
- Every field pre-written, with a fill-in guide for each placeholder
- The complete "why WCAG 2.2 AA" reasoning, ready to stand behind if a visitor or a plaintiff's attorney asks
- The WCAG 2.2 self-audit checklist, so your "substantial conformance" claim is backed by an actual audit trail
- A companion remediation plan template for tracking the gaps you find across theme, builder, and plugins
Ship a statement that's actually defensible
Core Kit ($99) includes the accessibility statement template, the WCAG 2.2 self-audit checklist, a remediation plan template, and an internal accessibility policy.
Get Core — $99 Compare Core vs ProFAQ
Does WordPress core handle accessibility for me?
WordPress core itself has an accessibility-focused contributor team, but your specific theme, page builder, and installed plugins are separate products with their own accessibility posture — your statement should reflect that division rather than implying "built on WordPress" covers everything.
Do I need to list every plugin by name in my statement?
Not necessarily — naming plugin categories (forms, booking, chat, e-commerce) in the third-party content section is standard practice. If one specific plugin is a known, ongoing source of barriers, naming it plus a remediation note is more useful to visitors.
Is this legal advice?
No. This page and the linked templates are professional documentation resources, not legal advice, and using them does not create an attorney-client relationship. Have qualified counsel review your statement before it goes live, especially if you've received any prior accessibility complaint.