Most accessibility guides hand you a generic checklist. Add alt text. Fix your headings. Check your contrast. Create an accessibility statement.
That advice isn't wrong. But it skips the most important question: where are you starting from?
Because the action plan for a well built site that needs a few fixes is completely different from the action plan for a WordPress site running a theme from 2019 with an overlay widget slapped on top. And pretending those two situations need the same checklist is how people waste months patching a house that should have been torn down.
Step Zero: Be Honest About What You Have
Before you fix a single thing, answer this honestly:
Who built your site? A professional developer? A DIY site builder? Your nephew? A "web design" company that handed you a Squarespace template and called it custom?
What platform is it on? WordPress with a theme? Wix? Squarespace? A page builder like Elementor or Divi? A custom coded site?
Has anyone ever mentioned accessibility? Not as a sales pitch for an overlay widget. Has anyone actually looked at the code and talked about semantic HTML, heading structure, or keyboard navigation?
Can you view the source code? Do you own it? Can your developer make structural changes, or are you locked into whatever the theme provides?
These questions matter because they determine your actual path forward.
Path A: Your Site Was Built Right (It Just Needs Tuning)
If your site was built with clean, semantic HTML by a developer who understood accessibility, you're in good shape. Your action plan is genuinely about fixes and improvements.
Run an audit. Use Lighthouse, axe, and WAVE to identify specific violations. Test with a keyboard. Test with a screen reader. Document everything.
Prioritize the fixes. Level A violations first (these are the ones that completely block someone from using your site). Then Level AA. Focus on high traffic pages.
Common quick wins: missing alt text on a few images. A color contrast issue on a button. A form field that lost its label somewhere along the way. A missing skip navigation link.
This is the scenario where a checklist actually works. You have a solid foundation and you're polishing it.
Path B: Your Site Is on WordPress (Or Another Template Platform)
This is where most small businesses land. And this is where the advice gets uncomfortable.
WordPress themes and page builders (Elementor, Divi, Beaver Builder) generate their own HTML. You don't control the heading structure. You don't control the ARIA attributes. You don't control how the navigation works with a keyboard. The theme decides all of that, and most themes decide poorly.
You can add alt text to images. You can improve your content. You can choose better color combinations. Those are real improvements and they matter.
But you cannot fix the underlying HTML structure if the theme won't let you. You cannot make a dropdown menu keyboard accessible if the JavaScript powering it doesn't support keyboard events. You cannot add proper ARIA roles to components you didn't build and can't modify.
So your action plan looks different:
Fix what you can control. Alt text, content clarity, color contrast, descriptive link text.
Accept what you can't control. If the theme generates bad HTML, no amount of content editing will fix that.
Make a decision. Is patching enough to meaningfully improve the experience? Or are you spending time and money on a foundation that will never be truly accessible?
We've seen businesses spend thousands on accessibility remediation for WordPress sites, only to discover that the theme itself was the problem and always had been. That's money that could have gone toward a site built right from the start.
Path C: Your Site Has an Overlay Widget
If you installed AccessiBe, UserWay, EqualWeb, or any similar overlay product, here's your action plan:
Remove it.
That's step one. Overlay widgets don't make your site accessible. They often make it worse. They've been called out by disability advocacy organizations, rejected by courts as evidence of compliance, and the FTC fined AccessiBe for deceptive marketing.
An overlay gives you a false sense of security. It's a badge on a page that says "we're accessible" while the actual code underneath is still broken. We found a competitor in our space that had fake WCAG badges displayed on their site while simultaneously disabling text selection, meaning users who needed to copy text or interact with it through assistive technology were locked out. The badge meant nothing.
After removing the overlay, go back to Step Zero. What does the actual site look like underneath? Is the foundation worth saving?
Path D: You're Building a New Site
This is the best position to be in. Because accessibility is dramatically easier and cheaper to build in from the beginning than to retrofit later.
When Tyler starts a new site build, accessibility isn't a phase that comes after design and development. It's woven into the first line of code. Semantic HTML elements instead of generic divs. Proper heading hierarchy planned from the page structure, not added after the content is written. Every interactive element gets keyboard support from the moment it's created.
We build a custom AccessibilityToolbar into every site. Skip links are in the layout component. ARIA attributes are on every interactive element. Color contrast is verified before a design is approved, not after.
This isn't extra work. It's just how a site should be built. The same way you wouldn't build a house without doors wide enough for everyone to walk through, you don't build a website without code clean enough for everyone to use.
If you're about to invest in a new website, ask your developer these questions:
"How do you handle keyboard navigation?" If they don't have a specific answer, they haven't thought about it.
"What heading structure will you use?" If they say "whatever looks right," they don't understand semantic HTML.
"Will I be able to navigate the entire site without a mouse?" If they look confused, find someone else.
"Do you use overlay widgets for accessibility?" If they say yes, find someone else immediately.
The Accessibility Statement
Regardless of which path you're on, publish an accessibility statement on your site. Not because it's a legal shield (it's not a guarantee of anything). Because it demonstrates good faith.
Include: your commitment to accessibility. What you're actively doing about it. How someone can contact you if they encounter a barrier. And be honest about where you are. "We're actively working to improve the accessibility of our website" is better than pretending everything is perfect when it's not.
The Real Takeaway
The action plan isn't a universal checklist. It depends entirely on where you're starting.
If you have a clean codebase, fix and improve.
If you're on a platform that limits what you can control, fix what you can and make an honest assessment of whether the platform is holding you back.
If you have an overlay, remove it and reassess.
If you're building new, build it right the first time. It's the cheapest, fastest, and most effective path to a site that genuinely works for everyone.
Goggles on. Let's do this.