How to Choose an Accessible WordPress Theme Before You Buy

The European Accessibility Act came into force on June 28, 2025, requiring businesses selling into the EU to meet WCAG 2.1 AA. ADA Title III enforcement against private businesses remains lawsuit-driven, with courts consistently applying WCAG 2.1 or 2.2 AA as the de facto standard. Neither of those legal realities care about which WordPress theme you picked from a directory – but the theme you pick determines whether you can meet those standards at all.

WordPress’s “accessibility-ready” label sounds like a compliance certification. It isn’t. It’s a baseline review checklist that the WordPress Theme Review Team uses to filter out the worst offenders, and it misses most of WCAG 2.2 AA. Every theme decision made on that label alone is a structural decision made without the right information, because accessibility failures baked into a theme’s foundation are among the most expensive to fix after launch.

This guide gives you an 8-point framework to evaluate any accessible WordPress theme before you commit, using nothing but the theme’s publicly available demo URL and your browser.

---

What does “accessibility-ready” mean?

An accessibility-ready WordPress theme is one that has passed the WordPress Theme Review Team’s minimum checklist. That checklist requires: a visible skip link that activates on keyboard focus, keyboard navigation for all interactive elements, visible focus indicators, sufficient color contrast for text and UI elements, no auto-playing media, and correct use of HTML5 landmark elements or ARIA roles.

What the label does not verify: WCAG 2.2 success criteria introduced after the checklist was last substantively updated, including 2.4.11 (Focus Not Obscured), 2.4.12 (Focus Not Obscured Enhanced), and 2.5.3 (Label in Name). It does not test form error handling to WCAG AA specification, complex widget patterns such as modals and accordions, or the non-text contrast requirement under WCAG 1.4.11. The label is a floor, not a ceiling.

---

What “Accessibility-Ready” Actually Means – and What It Doesn’t Cover

The WordPress Theme Review Team does meaningful work. Themes that earn the accessibility-ready tag have cleared a real baseline. But the checklist was not designed to map to WCAG 2.2 AA in full, and the gap matters more than most buyers realize.

Here is exactly what the label covers versus what WCAG 2.2 AA actually requires:

WordPress Accessibility-Ready Checklist	WCAG 2.2 AA Requirement
Skip link present and keyboard-activatable	WCAG 2.4.1 – Bypass Blocks ✓ Covered
Keyboard navigation for all interactive elements	WCAG 2.1.1 – Keyboard ✓ Covered
Visible focus indicators	WCAG 2.4.7 – Focus Visible ✓ Covered (but not to 2.4.11/2.4.12 enhanced spec)
Color contrast for text (4.5:1 minimum)	WCAG 1.4.3 – Contrast Minimum ✓ Covered
No auto-playing audio	WCAG 1.4.2 – Audio Control ✓ Covered
HTML5 landmarks / ARIA roles	WCAG 1.3.1 – Info and Relationships ✓ Covered
– Not tested –	WCAG 1.4.11 – Non-Text Contrast (3:1 for UI components) ✗ Not covered
– Not tested –	WCAG 2.4.11 – Focus Not Obscured (focus not hidden by sticky elements) ✗ Not covered
– Not tested –	WCAG 2.4.12 – Focus Not Obscured Enhanced ✗ Not covered
– Not tested –	WCAG 3.3.2 – Labels or Instructions (form error handling) ✗ Not covered
– Not tested –	WCAG 2.5.3 – Label in Name ✗ Not covered
– Not tested –	Complex widget patterns: modals, accordions, tabs ✗ Not covered

The practical consequence: a theme can display the accessibility-ready badge and still fail a WCAG 2.2 AA audit on multiple criteria. That is not a loophole. It’s a documented limitation of what the badge was ever designed to do.

Why Your Theme Choice Has Legal Consequences

The theme layer controls heading structure, focus management, color tokens, ARIA landmark placement, and the base HTML that every page on your site inherits. A poorly built theme doesn’t create one accessibility problem. It creates a systemic one across every URL you publish.

ADA.gov’s guidance on web accessibility confirms that ADA Title III applies to private businesses, carries no government-mandated compliance deadline, and is enforced entirely through litigation. Courts have consistently applied WCAG 2.1 AA as the de facto standard, with WCAG 2.2 AA increasingly referenced in more recent settlements. According to UsableNet’s 2025 Year in Review, e-commerce accounts for approximately 70% of all web accessibility lawsuits filed in the United States, and WordPress powers a significant share of those stores.

For businesses with EU exposure, the stakes are more specific. The European Accessibility Act came into force on June 28, 2025, and applies to any company with 10 or more employees or €2M or more in annual turnover selling products or services into EU markets. WCAG 2.1 AA is the required standard. If your WordPress site sells anything to EU customers and you’re above those thresholds, you are already in scope.

The retrofit problem is real. Fixing theme-caused accessibility failures post-launch, including structural heading hierarchy, missing landmark roles, and stripped focus indicators, requires code-level changes to the theme itself, often touching hundreds of templates. Evaluate before you buy, not after.

For context on what this looks like across other platforms, Shopify Accessibility Compliance: Product Pages, Apps, and Checkout covers the same foundation-layer risks in a different CMS. The principle is identical.

The 8-Point Accessible WordPress Theme Checklist

Every check below can be run against the theme’s live demo URL without installing anything. Most premium theme vendors host a live demo. WordPress.org themes link to a preview. Use that URL. You do not need a test WordPress installation to run this evaluation.

1. Verify the Accessibility-Ready Tag – Then Look Deeper

Filter the WordPress.org theme directory by “accessibility-ready” to establish your shortlist. That tag eliminates the worst-performing themes and is a reasonable starting point.

What to look for: The tag in the theme’s directory listing. Then look at the theme’s documentation: does the vendor reference any WCAG version? Do they publish an accessibility statement or audit report?

Red flag: A theme that claims “WCAG compliant” or “WCAG 2.2 AA certified” without linking to an actual audit report. Any vendor can write marketing copy. An audit report with a date, a scope, and a named evaluator is evidence. A bullet point on a sales page is not.

2. Test Skip Links on the Demo Page

Navigate to the theme’s live demo URL. Press Tab once. The first visible element that appears should be a “Skip to main content” link.

What to look for: A visible link appears at the top of the page on the first Tab keypress, jumps focus to the main content area when activated, and then disappears when not focused (visible-on-focus is acceptable; permanently hidden is not).

Red flag: The Tab key cycles through the entire navigation menu, including the logo, each nav item, and dropdown submenus, before reaching the main content. On a site with a large navigation, that can mean 20 or more Tab presses before a keyboard user reaches what they came for.

3. Check Focus Indicators Are Visible

Tab through ten interactive elements on the demo: links, buttons, form inputs, dropdown triggers. Each one should show a clearly visible outline or highlight that moves with focus.

What to look for: A consistent, visible focus indicator on every interactive element. WCAG 2.4.11 (Focus Not Obscured) also requires that focus is not hidden behind sticky headers or persistent elements. Check this by tabbing into content below any fixed navigation bar.

Red flag: At any point in the tab sequence, you cannot see where keyboard focus currently is. This is the single most common keyboard accessibility failure, and it is almost always deliberate. Many themes suppress focus outlines with outline: none or outline: 0 in their stylesheet for aesthetic reasons. To verify this, open DevTools, go to the Elements panel, and search the theme’s CSS files for outline: none or outline: 0. If those declarations appear on links, buttons, or interactive elements without an alternative focus style defined, that theme is failing WCAG 2.4.7 by design.

When we tabbed through a typical “accessibility-ready” theme demo and found no visible focus indicator on navigation links, inspecting the stylesheet confirmed exactly this: a:focus { outline: none; } in the main theme CSS. The badge doesn’t catch it.

4. Verify Color Contrast on the Demo

Body text requires a contrast ratio of at least 4.5:1 against its background (WCAG 1.4.3). Large text, defined as 18pt (24px) or larger, or 14pt bold, requires 3:1. These thresholds apply to normal and hover states.

What most buyers miss: WCAG 1.4.11 requires a 3:1 contrast ratio for non-text UI components, including button borders, input field outlines, focus ring colors, and form element boundaries. A theme can pass 1.4.3 for body text and still fail 1.4.11 for its button styles.

According to the 2026 WebAIM Million report, low-contrast text appeared on 83.9% of home pages analyzed, making it the most common accessibility failure for the seventh consecutive year. It is also one of the easiest to check before you buy.

What to look for: Body text with clear contrast, particularly in grey-on-white color schemes. Check ghost buttons (outlined buttons with transparent backgrounds) specifically – their border color often fails 1.4.11.

Red flag: Pale grey body text on a white background. Ghost buttons where the border is close in value to the background. Placeholder text styled at low contrast (placeholder text is exempt from 1.4.3, but inputs styled to look like placeholder text often have invisible borders that fail 1.4.11).

5. Inspect the Heading Hierarchy

Load the demo page. Open DevTools, go to the Elements panel, and look at the heading structure from H1 through H6.

What to look for: Exactly one H1 per page (usually the page title or hero headline). H2s used for major sections. H3s used for sub-sections within H2s. Headings should follow logical nesting with no jumps from H1 to H4.

Red flag: Multiple H1 elements on a single page. Headings used for their default visual size rather than their document structure role. A theme that styles H3 as large decorative text and applies it regardless of nesting position breaks the document outline that screen reader users navigate by.

6. Check ARIA Landmarks and Semantic HTML

Right-click the demo page and select View Page Source. Search for <header>, <nav>, <main>, and <footer>. Alternatively, open DevTools and inspect the document structure directly.

What to look for: Native HTML5 landmark elements or their ARIA equivalents: role="banner" for the site header, role="navigation" for nav, role="main" for the primary content area, role="contentinfo" for the footer. Without these, screen reader users cannot jump between sections. They must navigate the entire page linearly.

Red flag: A page structure built entirely from <div> and <span> elements with no semantic roles. This is a sign the theme was built without accessibility consideration at the markup level, and markup is the hardest layer to fix after the fact.

7. Test Forms and Interactive Elements

If the theme demo includes a contact form, newsletter signup, or search field, test it.

What to look for: Every input field has a visible <label> element that remains visible when the field is focused. Button text describes the action it performs. Icon-only buttons (search icons, social share icons) have an aria-label attribute that provides the text equivalent.

Red flag: Input fields that use placeholder text as the only label. The placeholder disappears when a user starts typing, leaving them without context. Icon-only buttons with no aria-label. A search field labeled “Search” that becomes unlabeled once the user clicks into it.

8. Scan the Demo URL With an Automated Accessibility Scanner

Here is the check that none of the competing guides explain clearly: you do not need to install the theme to scan it.

Every theme vendor’s live demo is a publicly accessible URL. Run it through an automated accessibility scanner exactly as you would any live site. The scan will surface WCAG 2.2 issues that the manual checks above may not catch: missing image alt attributes, duplicate element IDs, ARIA misuse, form fields without associated error messages, and contrast failures across the full page.

A five-minute scan on the demo URL costs nothing. A theme-level remediation after launch, involving restructured heading templates, added landmark roles, and fixed focus management across widget patterns, can take weeks of developer time.

Run the demo URL through a free website accessibility checker before you make a purchase decision. You’ll have a documented list of failures before you spend a dollar.

---

How to Run a Pre-Purchase Theme Scan (Step-by-Step)

This workflow takes under 30 minutes and requires no developer, no WordPress installation, and no paid tools.

Here is how the main pre-purchase testing methods compare for evaluating an accessible WordPress theme:

Test Method	What It Catches	Time Required	Requires Installation
Manual keyboard test	Skip links, focus indicators, tab order	5 min	No
DevTools inspection	Heading hierarchy, semantic HTML, CSS issues	10 min	No
Automated scan on demo URL	WCAG 2.2 violations, missing labels, contrast, ARIA errors	5 min	No
Post-install manual audit	Complex interactions, dynamic content, plugin conflicts	60+ min	Yes

Step 1: Find the theme’s official live demo URL. For WordPress.org themes, use the Preview button. For premium themes, check the vendor’s pricing page – most link a live demo.

Step 2: Open the demo URL in your browser. Do not use a mobile browser for this – you need DevTools access.

Step 3: Run the keyboard test. Press Tab from the top of the page and work through ten interactive elements. Record any point where focus becomes invisible.

Step 4: Open DevTools. Search the Elements panel for outline: none and outline: 0 in the theme’s CSS. Check the heading structure. Confirm landmark elements are present.

Step 5: Run an automated accessibility scan on the same demo URL. Use a free website accessibility checker or check our guide to WAVE Accessibility Checker Alternatives That Don’t Require Sign Up for options that work without creating an account.

Step 6: If you have two finalist themes, run the same protocol on both. The one with fewer automated scan errors and a clean keyboard test is the lower-risk starting point.

Document what you find. If you later need to demonstrate due diligence in an ADA demand letter situation, a pre-purchase audit record is worth having.

Red Flags That Mean: Skip This Theme

These are dealbreakers. If a theme you’re evaluating shows any of the following, move to the next option.

• No skip-to-content link on first Tab press. The theme fails WCAG 2.4.1. Every keyboard user and screen reader user will navigate the full menu on every page load.
• Hover-only navigation menus. Menus that open only on mouse hover are inaccessible to keyboard users and unreliable on touch devices. This is a structural pattern problem, not a styling fix.
• outline: none on focused elements with no alternative style. Deliberate focus indicator suppression. Check the stylesheet directly – do not assume a visible style exists on states you haven’t tested.
• Fixed pixel font sizes. A theme that sets body text at font-size: 14px rather than using rem or em units will not scale when a user increases their browser’s default font size. This affects users with low vision who rely on browser zoom.
• Inline color styles that override the cascade. If the theme applies colors as inline style attributes rather than CSS classes, users running Windows High Contrast mode or custom stylesheets cannot override them. That breaks entire user populations.
• Inaccessible modals or lightboxes. Test any modal in the demo. It should trap keyboard focus within the modal while open and have a keyboard-accessible close button. If Tab escapes the modal into the background content, the theme’s JavaScript widget patterns are broken.
• Placeholder-only form labels. Any theme using placeholder text as a substitute for <label> elements is failing WCAG 1.3.1 and will create form completion problems for screen reader users and users with cognitive disabilities.
• Missing lang attribute on the <html> element. View source and check the opening HTML tag. It should read <html lang="en"> or the relevant language code. Without it, screen readers cannot select the correct voice or pronunciation engine.
• A broken or 404 demo page. If the vendor cannot maintain their own demo, they are not actively maintaining their theme. A vendor who lets their demo break will not ship accessibility-related updates.

After You Choose: Accessibility Doesn’t Stop at the Theme

The theme is the foundation layer. Once it’s installed, three things routinely introduce new violations before your site has been live for a month.

The first is popup and overlay plugins. Most popup builders do not trap keyboard focus within the popup, do not announce their presence to screen readers, and do not restore focus to the triggering element when closed. A keyboard-accessible theme can be rendered inaccessible in minutes by a badly built popup.

The second is image content. Every image block added without alt text, whether by a developer, a content editor, or a page builder, creates a new WCAG 1.1.1 failure. The theme cannot prevent this. Only a content workflow that makes alt text a required field can.

The third is form plugins. Contact Form 7, Gravity Forms, WPForms: each has its own accessibility track record, and each can introduce label association failures, missing error messages, or focus management problems that a clean theme cannot compensate for.

The Click-Away Pound Survey 2019 found, as directional figures, that 69% of disabled online consumers reported clicking away from sites they found difficult to use. Theme selection reduces the baseline failure rate, but ongoing monitoring is what keeps it low.

Once your theme is in place, run How to Check Your Homepage for ADA Accessibility Issues as your first post-launch audit. Then set a recurring scan schedule, because a single snapshot at launch becomes stale fast.

Frequently Asked Questions

Is “accessibility-ready” the same as WCAG 2.2 compliant?

No. The accessibility-ready label confirms a theme passes WordPress’s baseline review checklist. WCAG 2.2 Level AA has 50+ success criteria; the WordPress checklist covers fewer than 15. For legal defensibility under ADA Title III or the European Accessibility Act, WCAG 2.2 AA is the current standard courts and regulators reference, not the WordPress theme tag.

Can I make any WordPress theme accessible after buying it?

Making any WordPress theme accessible after purchase is technically possible but rarely cost-effective. Themes that lack semantic HTML, correct focus management, or proper ARIA landmark structure require deep code changes, often across multiple template files. Choosing an accessible WordPress theme at the start is substantially cheaper than retrofitting one. The labor cost of post-launch remediation for structural failures typically runs into thousands of dollars.

Do I need an accessible theme for ADA compliance?

ADA Title III does not name specific technical standards, but federal courts consistently reference WCAG 2.1 or WCAG 2.2 AA in settlements and demand letters. An inaccessible theme creates structural barriers, including missing landmarks, broken keyboard navigation, and stripped focus indicators, that an overlay plugin alone cannot fix. Those barriers leave your site exposed to demand letters regardless of any surface-level remediation applied on top.

How do I test a WordPress theme’s accessibility without installing it?

Use the theme’s official live demo URL. Run a keyboard tab-through to check focus visibility and skip link behavior, open DevTools to inspect heading structure and semantic HTML, and run an automated accessibility scan against the demo URL directly. None of those steps require a WordPress installation or a purchase. The entire pre-purchase workflow takes under 30 minutes.

---

The 8-point checklist gives you an objective framework to compare any theme on accessibility grounds before you spend anything. The pre-purchase scan workflow is the single highest-leverage action available to you: five minutes against a demo URL now versus weeks of developer remediation later.

Run a scan against your prospective theme’s demo at accessibilityscanner.org before you make a final decision. If the theme can’t pass a scan on its own demo page, it won’t pass on your site.

This article is for general informational purposes and is not legal advice.