You installed a WordPress accessibility checker, opened a page in the editor, and a panel told you there are 14 errors, 37 warnings and something called “needs review”. Some of the items make sense. Others point at code you have never seen, or flag an image you are sure has alt text. Now what?
This post is about the checkers that run inside your dashboard: what they actually look at, how to read their warnings, which flags are often false alarms, and how to scan WordPress for accessibility across every template rather than one page at a time. It does not compare outside browser tools; those belong to testing, which is covered separately.
What an in-dashboard checker does
A dashboard checker is a plugin that looks at the HTML of your posts and pages and compares it against a list of rules. Most show results in a panel beside the editor, and some also offer a site-wide report that lists issues by page. A few run their scan when you save; others scan on request.
The rules are things a machine can decide on its own. Is there an image without an alt attribute? Does a heading level jump from H2 to H4? Is there a link with no text inside it? Does this text color have enough contrast against the background color set in the markup? Those are useful questions, and finding them early saves time.
What it cannot do is judge meaning. A checker can tell that alt text exists. It cannot tell that “IMG_4471” or “image” is useless, or that the alt text on a chart leaves out the number the chart is about. It cannot press Tab through your menu or listen to your contact form with a screen reader. Automated rules cover only part of WCAG, and the rest needs a person.
Checkers are not fixers or overlays
Some plugins mix checking with automatic “fixes”, and some add a front-end toolbar. Those are different jobs. A checker reports; it changes nothing on its own. If you want the bigger picture of which kind of plugin does what, our guide to choosing WordPress accessibility plugins sorts them out.
How to read the results
Most checkers sort findings into something like errors, warnings and items to review. The labels vary by plugin, but the idea is similar.
| Type of result | What it usually means | What to do |
|---|---|---|
| Error | The rule failed in a way a machine can be fairly sure of, such as an empty link or a form field with no label. | Confirm it on the page, then fix it. These are rarely false. |
| Warning | Something might be a problem depending on context, such as a long alt text or a link that opens a new window. | Look at it with your own eyes and decide. |
| Needs review | The tool knows it cannot judge this, such as whether a video has captions or whether link text makes sense. | Treat it as a to-do for a manual check. |
Every good finding should tell you which element is involved and, ideally, which WCAG success criterion it relates to. If your checker shows the criterion number, write it down with the issue. It makes later conversations with a developer much shorter.
Start with what repeats
If the same error shows on every page, it almost always lives in the theme, the header, the footer or a plugin, not in your content. An empty link in the footer social icons will appear on all 80 pages of the site, and fixing it once in the template removes all 80. So sort by how often an issue appears before you sort by page.
False positives you will meet
Checkers are built to be cautious, which means they flag things that turn out to be fine. These are the usual suspects on WordPress sites.
- Contrast on text over images or gradients. The tool can only see the colors in the code. Text sitting on a photo may pass or fail depending on the part of the photo behind it. Check it by eye with a contrast checker on the actual spot.
- Contrast in the editor versus the live page. The editor may load slightly different styles from the front end. Always confirm a contrast warning on the published page.
- Decorative images with empty alt. An image with
alt=""is the correct way to hide a decorative image from screen readers, yet some tools flag it as “missing alt text”. If the image adds nothing, leave it empty. - Links that open in a new tab. These are often warnings, not failures. They are fine when you tell people a link opens a new tab.
- “Possible heading” warnings for bold paragraphs. Sometimes the bold text is a real heading and should be one; sometimes it is just emphasis. You decide.
- Issues inside third-party embeds like maps, booking widgets or video players. The checker may not see inside them at all, or may report problems you cannot change without replacing the embed.
Most checkers let you dismiss or ignore a finding. Use that only after you have looked at it, and if the plugin allows a note, write why. “Decorative divider, empty alt is correct” is more useful in six months than a silent dismissal.
And the problems it will miss
The reverse matters more. A clean report does not mean the page works. Keyboard traps, hidden focus, a dropdown that only opens on hover, a popup that never returns focus, a form error only shown in red, a carousel that will not stop: a checker reading HTML typically will not catch these. The piece on what automated tools can and cannot judge goes into why.
How to scan WordPress for accessibility across the whole site
Checking one page in the editor tells you about that page. A WordPress site, though, is mostly built from templates, and the same template serves hundreds of URLs. A sensible scan covers each template at least once.
- List your page types. Homepage, a standard page, a blog post, the blog archive, a category page, search results, the 404 page, the contact page, and any landing pages built differently. On a store, add a product, the shop page, cart, checkout and the account page.
- Pick one real example of each. Choose a page with typical content, not an empty test page.
- Run the checker on each one. Use the site-wide report if your plugin has one; otherwise scan each URL.
- Group the findings. Template issues (header, footer, sidebar, theme layout) in one list; content issues (a missing alt, a skipped heading in one post) in another.
- Fix the template issues first. They affect the most pages.
- Re-scan the same set of pages after fixes to confirm the count dropped.
Remember that some pages are hard for a dashboard checker to reach. Search results, 404 pages, logged-in account pages and checkout steps may not appear in an editor panel at all. These are often the pages where real barriers hide, so make a note to check them another way.
Using a checker day to day
The best use of an editor checker is as a habit for whoever writes content. Before pressing Publish on a new post, glance at the panel. Fix the missing alt text, the empty heading, the “click here” link. Done every time, it keeps new problems from piling up.
For the people who manage the site, a monthly site-wide scan is a good early warning. If the error count suddenly jumps after an update, something in a theme or plugin changed. That is a cue to look closer, not a full test in itself.
Keep it light on the server
Some checkers scan in the background and store their results in the database. On a large site, a full scan can take a while and add load. Run big scans at quiet times, and if the plugin stores old reports, clear them out now and then.
Where a WordPress accessibility checker fits in the bigger job
A checker is the first pass, never the last. It finds the obvious machine-checkable issues so that human testing time goes on the harder ones. After the scan comes a keyboard pass, a screen reader pass and a zoom check, which our full website accessibility testing method walks through step by step. For the order of work on a WordPress site as a whole, see our guide to making your WordPress site accessible.
If you want a second pair of eyes on your scan results before you start fixing, a free website accessibility check is a reasonable first step. It is not a full audit, but it helps sort real problems from noise. For an overview of audits, remediation and monitoring, see our accessibility services for US businesses.
Frequently asked questions
Is a WordPress accessibility checker enough to meet WCAG?
No. A checker reviews the code for rules a machine can test, which covers only part of WCAG 2.2. Keyboard use, screen reader output, focus order, meaningful alt text and clear error messages need a person to check. Use the checker to catch the easy issues, then test by hand.
Why does my checker show errors that are not on the page?
The issue may come from markup you cannot see, such as a hidden menu, an icon link in the footer or code from a plugin. Some checkers also scan the editor view, which can differ from the live page. Find the element the report names and confirm it on the published page before fixing.
Should I fix every warning?
Fix every confirmed error. Read each warning and decide whether it applies in context, because many are prompts to check something rather than failures. If you dismiss one, note the reason so that whoever looks at the report next understands why it was left.
Can a dashboard checker scan pages built with Elementor or Divi?
It depends on the plugin. Some checkers read the published page, which includes builder output, while others only look at the classic content area. Test it: run the checker on a builder page with a problem you already know about, such as an icon link with no name, and see whether the report catches it.
We use dashboard scans as the starting point on WordPress sites, then test templates by keyboard and screen reader and fix what turns up in the theme, plugins and content. If you would like that done for your site, see our accessibility work for WordPress sites.
Next in this series: Accessible Carousel: Making Sliders Usable for All
