<div class="btn" onclick="book()">
Book now
</div>
<button type="button" onclick="book()">
Book now
</button>
Overlay widgets promise compliance from one line of code. It’s an appealing offer, and it’s why thousands of small businesses installed one. But an overlay doesn’t change your website. It loads on top of it and tries to patch problems in the visitor’s browser — guessing at labels, rewriting structure on the fly, adding a toolbar. Your underlying code stays exactly as broken as it was.
The consequences are practical, not theoretical. Screen-reader users frequently report that overlays make sites harder to use, not easier — some install browser extensions specifically to block them. Businesses running overlays have continued to receive accessibility lawsuits. Regulators have taken action against overstated compliance claims in this market. And the moment the script fails to load, or the subscription ends, every “fix” vanishes at once.
Who it’s for
We’re happy to work from another vendor’s audit — you don’t need to buy ours first. If the report is thin or unclear, we’ll tell you honestly what’s missing before we quote.
Semantic HTML structure
Real headings, landmarks and elements, so assistive technology understands your page.
ARIA, used correctly
Added where it genuinely helps, removed where it’s doing harm. Bad ARIA is worse than none.
Keyboard accessibility
Every menu, form and control operable without a mouse, with no traps.
Focus management
Visible focus, logical order, and focus that lands where it should in menus and modals.
Forms and error handling
Proper labels, clear required fields, and errors that are actually announced.
Navigation and menus
Dropdowns and mobile menus that work for keyboard and screen-reader users.
Color contrast
Text and interface elements corrected to meet AA, without wrecking your brand.
Images and alternative text
Meaningful descriptions written by a person, decorative images correctly hidden.
Interactive components
Accordions, tabs, modals and carousels rebuilt to behave properly.
5
No keyboard access and no accessible name — a keyboard or screen-reader user can't activate it.
Before
<div class="btn"
onclick="go()">Menu</div>
After
<button type="button"
onclick="go()">Menu</button>
What changed: a real button element — focusable, and operable with Enter and Space.
A screen reader announces only the file name — "IMG_4821 dot jpg" — instead of the destination.
Before
<a href="/menu">
<img src="IMG_4821.jpg">
</a>
After
<a href="/menu">
<img src="IMG_4821.jpg"
alt="View our menu">
</a>
What changed: meaningful alt text, so the link's purpose is announced.
The placeholder vanishes on typing, and a screen reader announces the field as blank.
Before
<input type="email"
placeholder="Email">
After
<label for="email">Email</label>
<input type="email" id="email">
What changed: a real, persistent label tied to the field.
Remediation goes wrong when the person writing the report and the person touching the code never speak. Khokon has spent 15 years building websites for clients across the US and EU, and audits ADA accessibility professionally — including remote work with a Los Angeles agency. The same person who identifies the issue implements the fix and verifies it, which is why nothing gets lost in translation.
Every quote is fixed scope and fixed price, written down before work begins. If the audit reveals your site is so structurally broken that fixing it costs more than rebuilding it, we’ll tell you that instead of quietly billing the hours.
FAQ
Rarely in any noticeable way. Most fixes are structural — in the markup and behavior, not the visual design. Where a contrast fix is needed, we adjust colors carefully to meet AA while staying true to your brand.