Many developers building personal websites—portfolios, blogs, small business sites—assume installing an AI-powered “accessibility overlay” (like those from UserWay, AccessiBe, or EqualWeb) satisfies WCAG compliance. It doesn’t. Worse, it creates a dangerous illusion of safety—especially when JavaScript-driven interactions, live regions, or dynamically updated ARIA attributes are involved. Meanwhile, the free, open-source WAVE evaluation tool consistently surfaces critical ARIA failures that overlays not only miss but actively obscure. This isn’t theoretical: it’s observable, reproducible, and has real consequences for screen reader users navigating your site.
Why overlays fail where dynamic ARIA matters most
AI overlays operate as client-side scripts that inject UI controls (e.g., “increase contrast,” “read page aloud”) and attempt to auto-correct common issues—adding role=\"button\" to <div>s, injecting aria-labels, or forcing skip links. But they work *statically*: they scan the DOM at load time and apply heuristics based on patterns. They cannot understand intent, context, or timing. When your site uses React, Vue, or vanilla JS to update content without full page reloads—such as a live search results list, a collapsible FAQ section, or a form with real-time validation—the overlay’s initial scan becomes obsolete. Its injected ARIA attributes may persist on elements no longer relevant—or worse, conflict with developer-intended ARIA states.
Consider aria-live. A properly implemented live region announces updates to screen readers *only when content changes meaningfully*. An overlay might blindly add aria-live=\"polite\" to every <section>, causing constant, irrelevant chatter. Or it might leave a critical live region entirely untouched because its selector logic didn’t match the custom class name you used. Neither scenario is caught by the overlay—it lacks runtime awareness. And crucially, the overlay itself introduces new focus traps, keyboard navigation breaks, and conflicting aria-hidden values that degrade—not improve—accessibility.
How WAVE detects what overlays ignore: The case of dynamic ARIA
WAVE (Web Accessibility Evaluation Tool) is a browser extension and web-based validator developed by WebAIM. Unlike overlays, WAVE does not attempt to “fix” anything. It analyzes the rendered DOM *as it exists at the moment of evaluation*—including content added or modified after page load. When you trigger a JavaScript interaction (e.g., opening a modal, submitting a form, filtering results), you can re-run WAVE and immediately see newly surfaced errors: missing aria-labelledby on dynamically inserted modals, aria-expanded mismatches on toggles, or role=\"alert\" elements lacking proper live-region semantics.
This capability stems from WAVE’s design philosophy: it prioritizes *detection over intervention*. It reports violations with precise line numbers, visual indicators in the page (highlighted icons), and plain-language explanations. For example, if your SPA updates a cart counter with innerHTML but forgets to include aria-live=\"polite\", WAVE flags “ARIA Live Region Missing” with a direct link to the problematic element. It doesn’t guess—you see exactly what’s wrong, in context.
“Overlays promise quick fixes but deliver shallow compliance. WAVE reveals the truth: whether your dynamic ARIA works *in practice*, not just in theory.” — Dr. Sarah Pulfer, Senior Accessibility Researcher, WebAIM
Side-by-side comparison: What each tool actually catches
| Issue Type | AI Accessibility Overlay | WAVE Evaluation Tool |
|---|---|---|
Missing alt on static images |
✅ Often adds generic alt text via image recognition (frequently inaccurate) |
✅ Reports missing alt; highlights exact image |
aria-expanded mismatch on JS toggle |
❌ No runtime monitoring; won’t detect state drift after user interaction | ✅ Detects mismatch *after* toggle is clicked; shows current value vs expected |
| Dynamic form validation errors | ❌ Rarely associates error messages with fields using aria-describedby post-submission |
✅ Flags orphaned error messages and missing aria-describedby relationships |
Live region without aria-live |
❌ Cannot identify content intended to be announced dynamically | ✅ Highlights non-live content that changes frequently—suggesting need for aria-live |
| Focus order disruption from JS insertion | ❌ May inject elements that break natural tab order; offers no warning | ✅ Shows focusable elements in DOM order; flags tabindex misuse and focus traps |
The table underscores a fundamental asymmetry: overlays optimize for volume (“fix 80% of static issues”), while WAVE optimizes for fidelity (“show you every violation in the current state”). For personal websites—where developers often hand-code interactive components and lack dedicated QA cycles—fidelity is non-negotiable. A single unannounced form error or skipped heading level can block a screen reader user from completing a contact submission or understanding your portfolio structure.
Real-world scenario: A portfolio site’s hidden failure
Alex, a front-end developer, launched their personal portfolio with a “Projects” section built in Vue. Each project card includes a “View Details” button that opens a modal via v-if. Alex installed AccessiBe, confident it handled everything. Screen reader users reported confusion: modals opened silently, with no announcement, and keyboard focus remained trapped on the trigger button. Alex ran WAVE *after clicking “View Details”*—and immediately saw two violations: (1) the modal lacked aria-modal=\"true\" and role=\"dialog\", and (2) the close button had no aria-label (“Close” was only visible text). Worse, WAVE highlighted that the modal’s heading (<h2>) wasn’t programmatically associated with the dialog via aria-labelledby.
Alex fixed all three issues in under 15 minutes—adding semantic HTML, managing focus with focus-trap, and ensuring aria-live announcements for success messages. They then disabled AccessiBe. Post-fix, WAVE showed zero errors in the modal flow. Crucially, Alex tested with NVDA and VoiceOver—and confirmed announcements worked, focus moved correctly, and users could dismiss the modal with Escape. The overlay hadn’t just missed these issues; its presence made debugging harder by injecting competing ARIA attributes and obscuring the real DOM structure.
Actionable audit workflow: From overlay dependency to reliable verification
Relying solely on an AI overlay is like trusting a spellchecker to proofread a legal contract. You need layered validation. Follow this sequence for any interactive component on your personal website:
- Build with semantic HTML first: Use native
<button>,<details>,<dialog>where possible—no ARIA needed. - Manually test keyboard navigation: Tab through all interactive elements. Does focus move logically? Can you open/close modals with Enter/Space/Escape?
- Trigger dynamic content: Submit forms, filter lists, expand accordions—then immediately run WAVE.
- Verify ARIA relationships: In WAVE’s sidebar, click “ARIA” tab. Confirm
aria-labelledby,aria-describedby, andaria-expandedvalues point to existing, visible elements. - Test with a screen reader: Use NVDA (Windows) or VoiceOver (Mac) to navigate the same flow. Listen for announcements, check heading levels, confirm labels match expectations.
This workflow takes 10–20 minutes per major interaction—but prevents hours of user frustration and potential legal exposure. It also builds deep, transferable knowledge about how assistive technologies interpret your code—something no overlay can teach you.
FAQ: Clarifying misconceptions
Do AI overlays violate WCAG?
Not inherently—but they frequently cause violations. Overlays commonly introduce aria-hidden=\"true\" on entire navigation menus (hiding them from screen readers), override native focus outlines (failing SC 2.4.7 Focus Visible), and inject redundant role attributes that conflict with native semantics (violating SC 4.1.2 Name, Role, Value). The overlay’s own interface often fails keyboard navigation and color contrast requirements.
Can I use WAVE alongside an overlay?
You can—but it’s counterproductive. Overlays alter the DOM in unpredictable ways (injecting <div>s, inline styles, and ARIA), making WAVE’s report reflect the overlay’s output—not your actual code. To get accurate results, disable the overlay before running WAVE. Treat the overlay as a separate, untrusted layer—not part of your accessibility foundation.
Is WAVE enough on its own?
No. WAVE excels at technical detection but cannot assess cognitive load, clarity of instructions, or whether a complex chart’s description is truly useful. Pair it with manual testing (keyboard-only, screen reader), user feedback (especially from disabled users), and semantic HTML best practices. WAVE is your microscope—not your entire lab.
Conclusion: Prioritize integrity over illusion
Your personal website is more than code—it’s your professional identity, your creative voice, your invitation to connect. Presenting it with broken ARIA, silent modals, or inaccessible forms doesn’t just risk compliance; it signals indifference to inclusion. AI overlays offer speed, but speed without accuracy erodes trust. WAVE offers truth—even when that truth is inconvenient. It reveals the gap between what you *intended* and what users *experience*. That gap is where real accessibility begins: not in automated injections, but in deliberate, tested, human-centered decisions.
Start today. Uninstall your overlay. Run WAVE on your homepage. Click every button. Fill out your contact form. Then run WAVE again. Note every error—not as a failure, but as a precise instruction. Fix one. Then another. Your site won’t become perfect overnight. But it will become honest. And honesty, in accessibility, is the first and most vital step toward belonging.
💬 Found a dynamic ARIA issue WAVE caught that your overlay missed? Share your experience in the comments—we’ll compile real examples to help others avoid the same pitfalls.
