Most WordPress themes do not conform to WCAG 2.1 AA. Even themes marketed as “accessibility-ready” routinely carry issues that only a (manual) accessibility audit can identify. If your site runs on WordPress, the theme is the foundation of your front-end code, and that foundation shapes whether your site is accessible or not.
WordPress powers a significant percentage of the web, and themes control layout, navigation, color, typography, and interactive elements. When a theme ships with inaccessible markup, every page on the site inherits those issues. An accessibility audit evaluates the rendered output of your site, and the theme is responsible for much of what gets evaluated.
| Consideration | Detail |
|---|---|
| Theme impact on conformance | Themes generate front-end HTML, CSS, and JavaScript that directly affect WCAG conformance across every page |
| “Accessibility-ready” tag | WordPress.org reviews themes against a partial checklist, not a full WCAG 2.1 AA evaluation |
| Common theme issues | Missing skip links, poor color contrast, inaccessible menus, incorrect heading hierarchy, missing form labels |
| How to determine conformance | A (manual) accessibility audit is the only way to determine WCAG conformance |
| Scan coverage | Automated scans only flag approximately 25% of issues |
What Does “Accessibility-Ready” Actually Mean?
WordPress.org maintains an “accessibility-ready” tag for themes in its directory. To earn the tag, a theme must pass a review against a set of requirements that covers areas like skip links, keyboard navigation, and form labels.
This review is not a full WCAG 2.1 AA evaluation. The accessibility-ready checklist addresses a subset of criteria. Themes that pass it can still carry dozens of conformance issues that go unidentified until a proper audit is conducted.
The tag is a positive signal, not a guarantee. Choosing an accessibility-ready theme is a better starting point than choosing one without the tag, but it does not eliminate the need for an audit.
Issues an Accessibility Audit Identifies in WordPress Themes
When Accessible.org conducts an audit on a WordPress site, theme-level issues appear consistently. These are issues baked into the theme code itself, not caused by content added after the fact.
Navigation menus: Dropdown menus that open on hover but cannot be operated with a keyboard. Submenus that trap focus or skip items entirely. Missing ARIA attributes that leave screen reader users without context for expandable menu structures.
Heading hierarchy: Themes that jump from H1 to H3, or use heading elements for visual styling rather than document structure. Screen readers rely on heading levels to convey page organization.
Color contrast: Theme color palettes that fail WCAG contrast ratios for normal text, large text, or interactive elements. Default link colors that are indistinguishable from surrounding body text without relying on color alone.
Form elements: Search bars, comment forms, and contact forms built into the theme without programmatic labels. Placeholder text used as the only label, which disappears on input and is not reliably announced by assistive technology.
Skip links: Missing or visually hidden skip links that do not become visible on focus, preventing keyboard users from bypassing repetitive navigation.
Focus indicators: CSS that suppresses the browser’s default focus outline without providing a visible alternative. This makes keyboard navigation functionally invisible.
Why Scans Cannot Replace an Audit for Theme Evaluation
Automated scans can detect certain theme issues, such as missing alt text on a theme’s default images or contrast ratios on specific color pairings. But scans only flag approximately 25% of issues.
A scan will not identify that a dropdown menu traps keyboard focus. It will not identify that a heading hierarchy is logically broken across templates. It will not identify that a form label exists in the HTML but is not programmatically associated with its input.
A (manual) accessibility audit evaluates how the theme behaves with keyboards, screen readers, and other assistive technologies. That evaluation is the only way to determine whether a WordPress theme conforms to WCAG 2.1 AA.
Does the Theme or the Content Cause the Issue?
This is a practical question that comes up during remediation. An audit identifies issues on the rendered page. Determining whether the theme or the content is responsible requires inspecting the source.
Theme issues live in PHP template files, CSS stylesheets, and JavaScript files within the theme directory. Content issues live in the WordPress editor, custom fields, or plugin output.
A missing form label on the search bar is a theme issue. A missing alt attribute on an image inserted into a blog post is a content issue. Both appear in an audit report, but they require different remediation paths. Theme issues often need a developer to modify template files or switch themes. Content issues can typically be corrected by editors directly.
What to Do After Your Theme Fails an Audit
Most themes will not pass an audit without modification. The question is whether the issues are fixable within the current theme or whether a theme change is more practical.
Minor issues like missing skip links or inadequate focus styles can often be addressed with a child theme or custom CSS and JavaScript. These are targeted fixes that do not require rebuilding the site.
Structural issues are different. If the theme generates inaccessible navigation markup, uses non-semantic HTML throughout its templates, or relies heavily on JavaScript that cannot be made accessible, remediation may cost more than migrating to a better-built theme.
Accessible.org regularly works with organizations that face this decision. The audit report provides the information needed to make it. Each issue maps to a specific WCAG criterion, and prioritizing those issues by user impact clarifies which path forward makes sense.
Choosing a WordPress Theme With Accessibility in Mind
For organizations selecting a new theme, a few factors reduce the risk of major conformance issues.
Start with themes tagged “accessibility-ready” in the WordPress directory. Filter further by checking whether the theme developer has a stated commitment to accessibility and a track record of addressing reported issues.
Evaluate the theme’s navigation, forms, and interactive components with a keyboard before purchasing or activating. If you cannot tab through the main menu and reach all interactive elements without a mouse, the theme has issues that will surface in an audit.
Block-based themes (Full Site Editing themes) introduce additional considerations. The block editor gives content creators more layout control, which means more opportunities to introduce accessibility issues at the content level. A well-built block theme provides accessible default blocks, but the output still depends on how those blocks are configured.
How Often Should a WordPress Site Be Audited?
An audit is a point-in-time evaluation. WordPress sites change frequently through theme updates, plugin updates, and new content. Any of these changes can introduce new issues.
A practical approach is to conduct an audit after launching a new theme, after major theme updates, and on a regular cycle that reflects how often the site changes. Organizations using the Accessibility Tracker Platform can track issue status over time and monitor whether remediated issues stay resolved across updates.
Can a premium WordPress theme guarantee WCAG conformance?
No. Premium themes are not audited against WCAG before release. A premium price tag reflects features and design, not conformance status. The only way to determine whether any theme conforms to WCAG 2.1 AA is through a (manual) accessibility audit.
Should I audit my theme separately from my full site?
A full site audit covers the theme because the theme generates the front-end output. There is no need for a separate theme-only audit. The audit report will identify which issues originate from the theme versus content or plugins.
Do WordPress accessibility plugins fix theme issues?
Some plugins address specific issues like adding skip links or improving focus indicators. They can supplement a theme but do not replace the need for accessible theme code. Plugins that apply overlay-style fixes do not resolve underlying markup problems and can introduce new issues.
Your WordPress theme is the largest single factor in your site’s accessibility posture. Knowing where it stands requires an evaluation that goes beyond automated tools and accessibility-ready labels.
Contact Accessible.org to schedule an accessibility audit for your WordPress site.
