Every WordPress site I have worked on in the last decade shares the same accessibility gap, and it is rarely the one people expect. The people involved care about accessibility. The problem is where their tool lives: a separate platform, another login, disconnected from the place where the work actually happens.
Accessibility gets made and unmade inside your everyday content workflow. It happens in the block editor when you choose a heading, in a media upload when you write or skip alt text, in the theme change you shipped last week, in the plugin you added yesterday. It sits right next to content and SEO as part of the on-page work you already do in WordPress. If your site runs on WordPress, your accessibility testing should run there too.
Your Site Changes Every Week. Your Testing Should Keep Up.
A WordPress site is never finished. Editors publish pages, someone updates a plugin, a theme tweak changes how a template renders. Any of these routine actions can introduce a barrier that was not there the day before. A page that scored perfectly last month can break the moment someone drops a background image behind white text.
Here are the kinds of everyday changes that quietly affect a single page’s accessibility:
- A new post published with missing headings
- A plugin update that changes a button’s markup
- A theme change that restructures navigation
- A hero image swapped behind existing text, breaking contrast
- Alt text left off a batch of uploaded images
None of these involve a mistake anyone would catch at the time. The site simply changed, which is what living websites do. Testing that happens only at formal intervals will always be looking at an older version of your site.
Testing in a Separate Tool Kills the Habit
Picture the workflow an external tool demands. You edit a page in WordPress, publish or preview it, switch to a separate tool, paste the URL, run a scan, read the report in that other interface, switch back, make changes from notes, then repeat the loop to confirm the fix.
Few teams keep that up. The friction turns accessibility into an occasional audit instead of a regular habit. The issues that get caught are the ones surfaced in a formal review, while the ones introduced by a Tuesday content update slip through until the next audit, if there is one. When the check happens inside the editor, the posts list, and the dashboard where you already work, accessibility becomes part of publishing rather than a separate project.
The Worst Problems Only Show Up in a Real Browser
The barriers your visitors hit come from several places. Some come from content, like a missing alt attribute or empty link. Some come from plugins that inject their own markup. Some come from the theme, in how it structures a template or its navigation.
Many of the most serious problems only appear once the page is rendered. Color contrast is the clearest example. A code-only scanner can compare a text color against a background color it reads in the source. It cannot tell that your white headline sits on the pale part of a hero image, or over video, where a real visitor cannot read it. You catch that only by looking at the page the way a browser draws it.
This is why a real browser environment matters. Loading the page in actual Chrome, the way a visitor’s browser would, surfaces rendered issues that source-level scanning misses. It does this whether the problem started in your content, a plugin, or your theme code, and it shows you exactly where on the page the issue lives.
Check Drafts and Custom Content Before They Go Live
The best fix is the one you make before a visitor ever hits the barrier. That means testing a page while it is still a draft, so the correction happens as part of writing instead of cleanup after a complaint.
It also means testing the content types your site actually runs on. Most sites are more than pages and posts. They are products, events, job listings, and other custom content that carries real business value and, often, real accessibility debt. Testing that reaches every content type, in draft, is testing you can act on before launch.
Automatic Scanning Beats a Weekly Schedule
A scheduled scan is always a step behind your site. Set a scanner to run weekly and here is the pattern. An editor publishes a page on Monday with a contrast problem. Visitors who rely on screen readers or keyboard navigation meet that barrier for six days. The scan finally runs on Sunday, by which point the issue is a week old and disconnected from the edit that caused it.
Automatic scanning changes the timing. The check runs when content is published, and again when published content is updated. The edit that introduces a problem gets tested right then, while the person responsible is still in the editor and the fix takes two minutes instead of an investigation. Add an alert that fires when a page drops to a critically low score, and you stop hunting for problems in a monthly report and start hearing about the serious ones as they appear.
A Page’s History Is Part of Your Legal Defense
Because the testing lives inside WordPress and attaches to the individual page, it builds something most external tools cannot: a history. Every scan of a page becomes part of that page’s record, so you can see how its accessibility has changed over time and show the progress you have made.
That record matters for more than motivation. If your organization ever has to demonstrate a good-faith, ongoing effort toward accessibility, a documented history of scans and fixes tied to specific pages is far stronger evidence than a single snapshot taken the week before a complaint. Accessibility work you can prove over time is a meaningful part of your legal position, not just an internal metric.
No Scanner Makes You Compliant
I want to be straight about the limits, because overpromising helps no one. No tool, mine included, can make your site compliant on its own. Automated scanning catches a real and valuable portion of accessibility issues, and a real browser environment catches more of them than code-only scanning does, but no scanner catches everything. Some things need a person who tests the page directly.
A human still has to check things like:
- Whether alt text is actually meaningful, not just present
- Whether the reading order and focus order make sense
- Whether the site is fully usable by keyboard alone
- How the page behaves with an actual screen reader
- Whether error messages and dynamic content announce themselves
The important part is that a good scanner does not replace that manual work. It clears so much of the routine detection out of the way that manual testing finally becomes realistic. When you are not spending your limited hours hunting for the issues software can find on its own, you can spend them on the judgment calls that need a person. A strong scanner is what makes serious manual testing affordable.
Skip the Overlays
One more thing worth saying plainly, because the marketing is everywhere. Accessibility overlays, the one-line-of-code widgets that promise instant compliance, do not do this job. They cannot fix semantic HTML, keyboard navigation, or content structure, and they often introduce new barriers while creating a false sense of safety. The accessibility community has been clear and consistent about this, and the Overlay Fact Sheet gathers the evidence and practitioner consensus in one place. Real accessibility means finding actual issues and fixing them at the source. No shortcut plugin does that for you.
How Insi Fits
This thinking shaped how we built Insi. The scanning engine runs in the cloud in a real browser environment, actual Chrome, so it catches rendered issues that code-only tools miss, including contrast over images and video, without loading down your server. The reporting, the issue list, and the workflow live natively inside WordPress. You scan drafts, published pages, and custom content from the editor, the posts list, or the dashboard. You see each issue pinpointed on the page with a plain-language explanation and a fix. Each scan attaches to the page and adds to its history, so you can track progress over time. And you can turn on automatic scanning so every publish and update gets checked on its own, with an alert the moment a page drops to a critical score.
None of that makes accessibility effortless, and it does not replace a human tester. Real remediation and real manual testing are still real work. What it does is put the automated part of that work where it belongs, inside the place you already build and maintain your site, and free up your time for the parts that need judgment.
Your website is WordPress. Your accessibility testing should be too.
Nick Longtin is the co-founder and CEO of Insi, a WordPress-native accessibility scanning platform. He has spent 25 years in web and more than a decade focused on WordPress accessibility, and he holds DHS Trusted Tester certification.