Last updated: September 23, 2026 · Skill level: intermediate.
Our WordPress theme accessibility test found that 12 of 20 popular theme previews scored 100 in Lighthouse’s automated accessibility category. The other eight scored from 82 to 96, with contrast, unlabeled controls, link names and landmarks among the detected issues. A perfect automated score is a screening result, not proof of WCAG conformance.
Key result: 12 of 20 popular WordPress theme preview pages scored 100 in this Lighthouse run.
How did we test WordPress theme accessibility?
We pulled the top 20 themes from the WordPress.org popular-theme API on September 23, 2026, then ran Lighthouse against each public preview page. The table records the theme version, accessibility score and failed automated audit labels returned on that page.
- Sample: 20 themes from the WordPress.org popular list.
- Page: each theme’s public wp-themes.com preview.
- Tool: Google Lighthouse accessibility category.
- Result: score plus failed automated audit labels.
- Scope: one preview page per theme; no custom content or plugin stack.
The WordPress.org preview toolbar and demo content can affect a result. A theme update, different starter site or content edit can change it. Lighthouse also cannot judge every WCAG success criterion, so the results should guide deeper testing rather than serve as compliance certificates.
What were the accessibility scores for all 20 themes?
Twelve preview pages returned 100. PopularFX had the lowest score at 82, followed by Envo Royal at 88, Hello Biz and Royal Elementor Kit at 90, and Twenty Twenty-Five at 91. The exact detected failures appear below.
| Theme | Version | Score | Failed audits | Detected issues |
|---|---|---|---|---|
| Twenty Twenty-Five | 1.5 | 91 | 2 | Form elements do not have associated labels; Select elements do not have associated label elements. |
| Hello Elementor | 3.5.1 | 100 | 0 | None detected |
| Astra | 4.13.12 | 95 | 1 | Background and foreground colors do not have a sufficient contrast ratio. |
| Twenty Twenty-Four | 1.6 | 100 | 0 | None detected |
| Kadence | 1.5.2 | 100 | 0 | None detected |
| Twenty Twenty-Three | 1.7 | 100 | 0 | None detected |
| Extendable | 2.1.9 | 100 | 0 | None detected |
| Hello Biz | 1.2.2 | 90 | 2 | Background and foreground colors do not have a sufficient contrast ratio.; Heading elements are not in a sequentially-descending order |
| OceanWP | 4.2.6 | 100 | 0 | None detected |
| Blocksy | 2.1.57 | 100 | 0 | None detected |
| Bluehost Blueprint | 1.0.2 | 100 | 0 | None detected |
| Twenty Twenty-One | 2.9 | 100 | 0 | None detected |
| GeneratePress | 3.6.1 | 100 | 0 | None detected |
| Twenty Twenty-Two | 2.2 | 100 | 0 | None detected |
| Twenty Seventeen | 4.2 | 96 | 1 | Links rely on color to be distinguishable. |
| Neve | 4.2.11 | 96 | 1 | Background and foreground colors do not have a sufficient contrast ratio. |
| Twenty Twenty | 3.2 | 100 | 0 | None detected |
| Royal Elementor Kit | 1.0.149 | 90 | 2 | Document does not have a main landmark.; Links do not have a discernible name |
| PopularFX | 1.2.7 | 82 | 4 | Buttons do not have an accessible name; Form elements do not have associated labels; Links rely on color to be distinguishable.; Select elements do not have associated label elements. |
| Envo Royal | 1.0.14 | 88 | 2 | Background and foreground colors do not have a sufficient contrast ratio.; Links do not have a discernible name |
Which accessibility problems appeared most often?
Color contrast was the most visible repeated theme-level issue, appearing in Astra, Hello Biz, Neve and Envo Royal. Other detected problems included form or select controls without labels, links without discernible names, links distinguished only by color, missing main landmarks and skipped heading levels.
- Contrast: text and background colors must remain readable across states.
- Labels and names: controls need programmatically associated text.
- Landmarks: the page needs meaningful regions such as main and navigation.
- Heading structure: levels should describe the content hierarchy.
- Link distinction: color alone should not carry the meaning.
Why does a score of 100 not prove accessibility?
Automated tools can identify only rules that software can evaluate reliably. They cannot decide whether alternative text communicates the right meaning, whether focus order follows the task, whether instructions are understandable or whether a screen-reader user can complete a purchase without confusion.
W3C recommends combining automated checks with human evaluation. Treat Lighthouse as a fast regression detector. Pair it with keyboard testing, at least one screen reader, 200% and 400% zoom, forced-colors or high-contrast modes, reduced motion and representative user tasks.
How should you test a theme before launch?
Test the built site, not only the vendor demo. Your plugins, colors, navigation, forms, blocks and editorial choices become part of the accessibility outcome.
- Install the theme on staging and import only the layout you plan to use.
- Navigate every interactive control with Tab, Shift+Tab, Enter, Space and arrow keys.
- Confirm a visible focus indicator and logical focus order.
- Use a screen reader to check landmarks, headings, names, status messages and forms.
- Run Lighthouse and axe on key templates, then inspect each failure manually.
- Zoom to 200% and 400% and test at a narrow viewport.
- Repeat after adding WooCommerce, forms, menus, popups and cookie controls.
- Create an accessibility regression checklist for future releases.
Which theme should you choose?
Start with themes that produced clean automated results, then choose based on your actual layout and testing capacity. A flexible theme can still become inaccessible through weak color choices or third-party blocks. A simpler theme with fewer interaction patterns is often easier to validate and maintain.
For block-first options, use our best WordPress block themes guide and our Full Site Editing guide. Our Astra vs GeneratePress comparison covers a separate performance and workflow intent.
How can the preview page affect the score?
A public theme preview combines theme code with sample content and the WordPress.org preview environment. A form added by the demo can create a label failure; a demonstration color can create a contrast failure. Conversely, a sparse preview can earn 100 without exercising menus, forms, comments, search, error messages or commerce components.
That does not make preview testing useless. It makes the result a reproducible first pass. When a failure appears, inspect the exact element to determine whether the theme, preview tooling or content created it. When no failure appears, add representative components and continue testing rather than declaring compliance.
How do page builders and plugins change accessibility?
The final experience is produced by the full stack. A page builder can replace theme markup, a popup plugin can trap focus, and a form plugin can introduce unclear errors. WooCommerce adds complex cart and checkout interactions. Test integrations together on the templates where visitors actually complete tasks.
- Header, desktop menu and mobile menu.
- Search, comments and contact forms.
- Archive pagination and filtering.
- Dialogs, popups, accordions and tabs.
- Cart, checkout, account and validation errors.
- Cookie consent and third-party embeds.
How should you fix a detected problem?
First identify ownership. Content issues belong in the editor, configuration issues may belong in theme settings, and code defects should be reported upstream with a minimal reproduction. Prefer a vendor update or child-theme fix over editing the parent theme because direct edits disappear on update.
For contrast, test every interactive state, not only normal text. For missing names, inspect the accessible name computed by the browser. For heading order, change the semantic level without choosing headings merely for visual size. For focus problems, preserve the native control whenever possible rather than rebuilding it with generic containers.
What evidence should a launch record contain?
Keep the tested URL, theme and plugin versions, browser, tool version, date, failures, manual tasks and fixes. Record who tested keyboard and screen-reader flows. This turns accessibility from a one-time score into an operational practice and makes future regressions easier to isolate.
How often should you retest?
Retest key templates before launch, after major theme or plugin updates, after navigation or checkout changes, and on a regular schedule. A monthly automated crawl can catch obvious regressions. Manual task testing should return for material interaction changes and at least during major releases.
Frequently asked questions
Does a Lighthouse score of 100 mean a theme is WCAG compliant?
No. Lighthouse automates only a subset of accessibility checks. A 100 score means no failure was detected in those automated audits on that tested preview page. It does not replace keyboard, screen-reader, zoom, content and user testing.
Can content make an accessible WordPress theme fail?
Yes. Editors can introduce low contrast, missing alternative text, unclear links, broken heading order, inaccessible forms and media. Plugins and page builders can also change the final markup and interaction model.
Which WordPress themes scored 100 in this test?
Hello Elementor, Twenty Twenty-Four, Kadence, Twenty Twenty-Three, Extendable, OceanWP, Blocksy, Bluehost Blueprint, Twenty Twenty-One, GeneratePress, Twenty Twenty-Two and Twenty Twenty scored 100 on the specific public preview pages tested.
What should I test before choosing a theme?
Test the exact demo and then your staged site with keyboard-only navigation, visible focus, screen-reader landmarks, headings, forms, menus, zoom, contrast, motion preferences and automated tools. Repeat after adding real plugins and content.
Sources and methodology
WPPRES tested the public previews for the 20 themes returned by the WordPress.org Theme API popular list on September 23, 2026. Automated checks used Google Lighthouse accessibility audits. Interpretation follows W3C guidance on evaluating web accessibility.
Leave a Reply