An accessibility-ready WordPress theme is a useful starting point, not proof that your finished website is accessible. The label concerns the theme review requirements. Your content, plugins, navigation, forms and customizations can still introduce barriers.
If a theme's label changes, first verify its current directory listing and review history. Do not assume the theme was removed from WordPress.org or that your website suddenly changed.
What is changing in the directory?
The WordPress Accessibility team's October 5 announcement describes a move toward a conditional accessibility-ready listing. Under that announced approach, not yet meeting the tag's requirements would not itself remove a theme from the directory, and adding the tag would act as an application for the accessibility listing.
The announcement also says implementation still needed some work. As of this October 19 source review, do not treat that announcement alone as proof that every directory workflow has switched.
The theme review handbook explains that accessibility-ready does not mean full WCAG AA conformance. Its workflow text was last updated before the October announcement. If you are submitting a theme, follow current reviewer guidance and the actual submission workflow rather than assuming the older procedural wording already reflects the transition.
Check the installed theme, not only its name
Record the exact parent theme version and whether a child theme changes templates, CSS or scripts. Compare the installed package with the theme's current official listing. A familiar name on an unrelated download site is not verification of the reviewed package.
Keep a short record containing the listing URL, check date, theme version and any review notes relevant to your decision. Do not turn a missing badge into a public accusation. It can reflect review status, a pending change or a problem that requires more evidence.
For a migration, run the site's own tests before switching production. The Ipsum staging migration checklist illustrates how to separate a theme evaluation from a live-site launch.
Test complete visitor tasks
Choose the pages people actually need: the main service page, contact form, account login, product page and checkout where applicable. A theme demo does not contain your real labels, validation errors or third-party widgets.
Start with keyboard-only navigation. Can you reach the menu, open its submenus, activate links and close overlays? Is focus visible throughout? Does a sticky header cover the focused control?
Next test a form with an intentionally missing required field. Check whether the error is understandable, associated with the field and reachable without guessing. Use synthetic details and a test delivery destination. Never submit a live payment merely to check a visual state.
At increased browser zoom, inspect navigation, headings, buttons and form errors. Long translated labels often expose problems that a short English demo does not. Record exact pages and steps, not a blanket "passed" checkbox.
Listing: Record exact theme and date. Tasks: Test real visitor journeys. Changes: Include plugins and child theme. Evidence: Keep scope and limitations. Proposed verification, not a customer test result.
Keep three evidence layers separate
| Evidence |
What it can support |
| Directory accessibility-ready listing |
Theme-review status under the directory's process |
| Tests of your configured site |
Observed behavior of your content, plugins and customizations |
| A scoped professional assessment |
Findings within its stated methods, pages and evaluation criteria |
An automated scan can locate some problems quickly, but it does not replace human testing of task completion. A screenshot also cannot establish screen-reader behavior. Avoid publishing a compliance claim based on either alone.
This is an operational checklist, not a legal determination. Where formal accessibility obligations apply, get an assessment appropriate to the business and its jurisdiction.
Fix the source of a barrier
If the parent theme works on a clean fixture but the child theme hides focus indicators, repair the child customization. If a form plugin fails to identify errors, changing the theme may not solve it. If link text is unclear, the content itself needs editing.
Prioritize issues that stop visitors completing the main task, then retest the complete path after each change. HandL WP can help trace a theme or plugin barrier, with the affected page and reproduction steps defining the work.
Recheck after meaningful changes
Retain a small repeatable set of visitor tasks for theme updates, menu rebuilds, new popups and form changes. Keep the results dated and scoped.
The practical question is not only "Does the theme have the tag?" It is "Can visitors complete the important tasks on this configured site, and what evidence do we have?"
References reviewed October 19, 2026. Diagrams and test fixtures are explanatory, not customer results.