You are choosing a theme for a new site, or wondering whether the one you have is the reason your accessibility scan looks so bad. In the WordPress theme directory you notice a filter for Accessibility Ready, and it seems like the obvious shortcut.
It is a useful starting point. Accessibility Ready WordPress themes have passed an extra review, but the tag describes the theme as submitted, with default content, not your finished site. This post explains what the tag covers, how to test any accessible WordPress theme yourself without technical skills, how block and classic themes differ, and what a child theme can fix when you would rather not switch.
What the Accessibility Ready tag actually checks
Every theme in the official directory gets a check from the theme team first. One that wants the Accessibility Ready tag goes through an additional set of accessibility checks run by reviewers. In general terms, these cover things such as:
- Keyboard navigation through menus and interactive parts, with a visible focus state.
- A skip link that lets keyboard users jump past the header to the content.
- A sensible heading structure in the theme’s templates.
- Text and link colors with sufficient contrast against the background.
- Links in body text that can be told apart from surrounding text by more than color alone.
- Labels on the theme’s own form fields, such as search and comments.
The exact list is published by the WordPress theme review team and changes from time to time, so treat the points above as the general idea rather than the official wording.
What the tag does not cover
Reviewers look at Accessibility Ready WordPress themes with their default settings and demo content. The review does not cover:
- The colors you choose in the customizer or site editor.
- The plugins you add, including page builders, sliders and form plugins.
- Your content: headings, alt text, link text, PDFs and video.
- Premium themes sold outside the official directory, which never went through this review at all.
So the tag is a sign that the developer cared about the basics. It is not a statement that the theme conforms to WCAG 2.2 AA, and it says nothing about your site once you have customized it.
How to test an accessible WordPress theme before you commit
Whether a theme has the tag or not, test its demo or a fresh install on a staging site before you build on it. You do not need to be technical for most of this.
- Tab from the top. Load the demo, click the address bar, then press Tab. The first stop should be a skip link. Keep pressing Tab and watch the focus outline move through the header. If it vanishes at any point, note where.
- Open the menu without a mouse. Use Tab, Enter and Space to open a dropdown and reach its items. Then shrink the browser window until the mobile menu appears and try the toggle button the same way.
- Zoom to 200 and then 400 percent. Text should get bigger and wrap; nothing should be cut off or need sideways scrolling to read.
- Scan three page types with a free tool like WAVE: the home page, a post and an archive page. Look at contrast errors and missing labels in the theme’s own parts: header, footer, search form, comment form.
- Check the headings. A browser extension or WAVE’s structure view lists headings. Look for a single main heading and no levels used purely for size in the header or sidebar.
- Listen briefly. Turn on NVDA or VoiceOver and move through the header. Do the logo, menu button and search have sensible names?
One pass through these steps tells you more than a feature list. Our broader post on checking the quality of a WordPress theme covers code quality, speed and support, which are worth checking at the same time.
Block themes vs classic themes
WordPress now has two kinds of themes, and they affect accessibility work differently.
| Block theme | Classic theme | |
|---|---|---|
| Where the header and footer are built | In the site editor, from blocks | In PHP template files, plus customizer settings |
| Who can change them | Site editors, without code | Usually a developer, via a child theme |
| Main accessibility risk | Editors can change heading levels, colors and menus easily, and break them | Fixes need code, so known problems tend to sit unfixed |
| Typical fixes | Adjust blocks, global styles and template parts | Override templates and CSS in a child theme |
Neither kind is automatically better. A block theme gives you more control without a developer, which helps if your team knows what to look for and hurts if they do not. The core Navigation block, for instance, aims to handle keyboard behavior for dropdowns and the mobile toggle, but the colors and labels you choose are still yours to check.
Common theme problems and where they are fixed
Theme problems repeat from one theme to the next. These are the usual ones, and where each fix belongs.
- Focus outline removed. Many themes include a CSS rule that hides the outline on links and buttons for looks. The fix is a visible focus style in the child theme or global styles. Our post on visible focus indicators under WCAG explains what a good one looks like.
- Skip link missing or broken. Sometimes it points to an ID that a page builder removed. Our guide to the skip to content link shows how to test it.
- Low-contrast defaults. Light gray body text, pale placeholder text in forms, and buttons with white text on a bright color.
- Logo link without a name. The logo image needs alt text that says the business name, since it doubles as the link home.
- Heading levels in widgets. Sidebar and footer widget titles output as H2 or H3 in a way that clutters the outline. Sometimes fine, sometimes confusing, depending on the page.
- Fixed-height headers. Headers with a set height overlap the content when text is zoomed or spacing is increased.
What a child theme can fix
If you like your classic theme and it is reasonably well built, a child theme is usually the right place for fixes. It is a small theme that inherits everything from the parent and only overrides what you change, so your fixes survive when the parent theme updates.
Typical child-theme fixes include:
- CSS for visible focus styles, better contrast, link underlines and spacing that holds up when text is enlarged.
- A corrected header template with a working skip link and a named logo link.
- Template overrides for search forms, comment forms or archive headings.
- Small scripts to make a custom menu toggle announce its open or closed state.
A child theme cannot fix everything. If the parent theme builds its menu, slider and layout from scripts that would all need rewriting, you are rebuilding the theme piece by piece. At that point a better base theme is often less work, and the decision belongs in a wider conversation about an accessible website redesign rather than patch after patch.
For the rest of the order of work after the theme, our guide to making a whole WordPress site accessible picks up from here.
A short checklist when choosing accessibility ready WordPress themes
- Has the theme been updated recently, and does the developer answer support threads about accessibility?
- Does the demo pass the keyboard, zoom and quick screen reader tests above?
- Can you change colors without losing contrast, and does the theme warn you or let you check?
- Does it work without a page builder, or does it depend on one for every layout?
- Is the demo full of sliders, animations and popups you would need to remove anyway?
A plain theme that passes these is a better foundation than a flashy one with the tag and a demo you will spend weeks undoing.
Frequently asked questions
Does an Accessibility Ready theme make my site accessible?
No. The tag means the theme passed an extra set of accessibility checks with its default settings and content. Your colors, plugins, page builder and content can all add barriers. It is a good starting point, not a result, and the finished site still needs testing by keyboard, zoom and screen reader.
Are premium themes less accessible than free ones?
Not necessarily, but premium themes sold on marketplaces outside the WordPress directory do not go through the directory review, so you have no outside check to rely on. Test the demo yourself with the keyboard, zoom and a scanner, and ask the developer directly what accessibility work they have done.
Should I switch to a block theme for accessibility?
Only if it fits the rest of your plans. Block themes let editors change headers, colors and menus without code, which helps fixes happen faster, but also makes it easier to introduce new problems. A well-built classic theme with a child theme for fixes can be just as accessible.
What if the theme developer will not fix an accessibility bug?
Report it once with clear steps to reproduce, such as which key you pressed and what happened. If nothing changes, fix it in a child theme where you can, and keep a note of the override. If the list of overrides keeps growing, start planning a move to a better-built theme.
If you want a second opinion on whether your current theme is worth fixing, our WordPress accessibility services start with exactly that question. You can also browse our website accessibility hub for the audit and monitoring side.
Next in this series: Elementor Accessibility: Fixing What Your Pages Output
