guide
WordPress accessibility for public-sector sites: setup, plugins, and audit checklist
Running an accessible WordPress site for public-sector sites combines two layers of responsibility: WordPress's platform-level accessibility, and the government-specific compliance frameworks — Section 508, ADA Title II, WCAG 2.1 AA — that layer on top.
Why WordPress for public-sector sites?
WordPress accessibility means making the world's most-used CMS (43% of all websites) conform to WCAG 2.2 AA — through accessible theme selection, core-supported gutenberg blocks, plugin discipline, and disciplined editorial workflow on alt text and headings.
Government accessibility — the regulated reality
Government accessibility — at federal, state, and local levels — is mandated in the US by Section 508 (federal) and the DOJ's April 2024 Title II rule (state/local, WCAG 2.1 AA), in the EU by the Web Accessibility Directive (EN 301 549), and in Canada by the Accessible Canada Act, making the public sector the most regulated digital surface globally.
WordPress accessibility challenges that hit public-sector sites hardest
• Inaccessible third-party themes
• Page builders (Elementor, Divi) injecting non-semantic markup
• Plugins adding inaccessible widgets
• Image lazy-loading without alt fallback
• Inaccessible Gutenberg blocks from third parties
Government pain points your WordPress site will likely have
• Inaccessible PDF forms and notices
• Inaccessible kiosks and ticketing terminals
• Outdated CMS platforms
• Procurement of inaccessible third-party services
• Lack of accessibility staff in smaller agencies
Setup steps
1. Choose an accessibility-ready theme: Filter the WordPress.org theme repository by "accessibility-ready". Avoid most ThemeForest themes without explicit accessibility documentation.
2. Audit your active plugins: Disable plugins one by one; re-test. Common offenders: cookie banners, social-share widgets, popup builders, "page speed" plugins that re-inject markup.
3. Editorial discipline on content: Train editors on heading hierarchy, alt text, link text, table headers. The most common WCAG failures originate in editorial workflow, not code.
4. Integrate continuous scanning: Wire axe-core into a CI scan on every deploy. Pair with quarterly manual audit.
FAQ
Frequently asked questions
Cited answers. Sourced. Updated as standards and case law change.
Can a WordPress site be made ADA compliant for public-sector sites?
Yes, provided the merchant or development team applies WCAG 2.2 AA at the source code and content level. No platform — including WordPress — guarantees compliance automatically.
What does the DOJ Title II final rule require?
WCAG 2.1 Level AA conformance for web content, mobile apps, kiosks, and self-service terminals operated by state and local government entities. Compliance deadlines: April 2026 for entities serving >50,000 residents; April 2027 for smaller.
How does Section 508 differ from ADA Title II?
Section 508 governs federal procurement of ICT and applies to vendors selling to federal buyers. ADA Title II governs state and local government services. Both reference WCAG. A federal contractor often complies with both simultaneously via a single VPAT.
Is WordPress core accessible?
WordPress core admin and the default themes (Twenty Twenty-Four etc) meet WCAG 2.1 AA. The accessibility coding standards require new core code to be accessible. The risk is in third-party themes and plugins, not core.
Are page builders like Elementor and Divi accessible?
They can produce accessible output but commonly do not by default. Elementor has invested in accessibility improvements since 2022; Divi remains the more problematic option. Both require manual auditing of the rendered output.
Stop guessing. Get the audit a Fortune 500 a11y team would have written.
Free audit on your live URL. No sign-up. IAAP-format report. Ready in hours.
founders@accessivepath.com · +977 9851094056