A11y Testing Tools for Vibe-Coded Frontends: AXE, Lighthouse, and Playwright

We’ve all seen them. The websites that look stunning. They have those smooth animations, the glassmorphism effects, and the complex interactive menus that feel like native apps. We call these vibe-coded frontends. But here is the harsh reality: most of them are unusable for people with disabilities. A 2023 survey by WebAIM found that 96.3% of one million home pages had detectable accessibility issues. If your beautiful interface breaks for screen reader users or keyboard navigators, you aren’t just missing out on users; you’re inviting lawsuits.

Automated tools can’t fix everything, but they catch the low-hanging fruit. For modern developers building dynamic interfaces with React, Vue, or Svelte, three tools stand out: axe-core, a JavaScript library created by Deque Systems to identify WCAG violations, Lighthouse, Google’s open-source auditing tool for web performance and accessibility, and Playwright, Microsoft’s cross-browser automation framework for end-to-end testing. Each plays a different role in keeping your frontend compliant with WCAG 2.1 and Web Content Accessibility Guidelines 2.2.

Why Vibe-Coded Frontends Need Special Attention

Vibe-coded frontends rely heavily on JavaScript frameworks and CSS-in-JS solutions to create rich user experiences. This complexity creates unique accessibility traps. Custom dropdowns might look great but fail to announce their state changes to screen readers. Modals might steal focus visually but not programmatically. Dynamic content loading can leave aria-labels empty until the data arrives.

The problem isn’t just aesthetics; it’s structure. When you build a custom component instead of using a native HTML element, you lose built-in accessibility features. You must manually add ARIA attributes, manage keyboard navigation, and ensure color contrast meets the minimum 4.5:1 ratio for normal text defined in WCAG 2.1. Automated tools help verify these manual additions don’t slip through the cracks.

Axe-Core: The Deep Dive Specialist

If you want raw power, you start with axe-core. Released as open source in 2016 by Deque Systems, this library is the engine behind many other accessibility tools. It doesn’t care about your scorecard; it cares about the code.

Axe-core injects directly into the DOM and runs 58 built-in rules covering WCAG 2.0, 2.1, and 2.2 standards. According to Deque’s internal benchmarks, it processes checks in 150-300ms per scan. That speed matters when you’re running tests frequently during development.

• Detection Rate: In CKEditor’s 2023 comparative study, axe-core detected 28 out of 30 test cases (93.3%).
• Strengths: Granular control over rules, ability to ignore specific false positives, and detailed violation explanations.
• Weaknesses: It catches only about 30-40% of total accessibility issues. Contextual problems like poor alt text quality require human judgment.

Developers love axe-core because it integrates everywhere. You can use it via the axe DevTools browser extension for immediate feedback while coding. Or, you can plug it into your CI/CD pipeline to block merges that introduce regressions. However, be prepared for a learning curve. Configuring axe-core to ignore valid framework-specific patterns, like dynamic class names in Tailwind CSS, often takes trial and error.

Lighthouse: The Quick Health Check

You probably already have Lighthouse installed. It comes built into Chrome DevTools since version 52. For quick validation before committing code, it’s unbeatable. Lighthouse 10.2.0 uses axe-core 4.6.0 under the hood for its accessibility audits, generating a simple 0-100 score.

The simplicity is both its strength and weakness. Developers find the 0-100 score intuitive, aiming for 90+ for “good” accessibility. But experts warn against treating this score as gospel. Adrian Roselli, an accessibility specialist, has called Lighthouse’s single metric “dangerously misleading.” Why? Because Lighthouse focuses only on automatically detectable issues. In Codoid’s 2024 benchmark, Lighthouse detected only 3 out of 9 test issues, compared to axe-core’s 7.

Use Lighthouse for awareness and quick checks. Don’t use it as your final compliance gate. It’s great for spotting missing alt tags or low contrast colors instantly, but it won’t tell you if your heading hierarchy makes logical sense for a screen reader user navigating a complex layout.

Playwright: The End-to-End Guardian

Here is where things get interesting for vibe-coded frontends. These applications are dynamic. Content loads asynchronously. States change rapidly. Static snapshots miss critical errors. This is where Playwright, introduced by Microsoft in January 2020, shines.

Playwright itself isn’t an accessibility tool. It’s an automation framework. But when paired with the @axe-core/playwright package, it becomes a powerful guardian for your entire user journey. Unlike Lighthouse, which takes a snapshot, Playwright interacts with your app. It clicks buttons, opens modals, and waits for network requests to finish.

This timing control is crucial. As documented in Playwright’s official guides, adding `await page.locator('#navigation-menu-flyout').waitFor()` before scanning prevents false negatives in single-page applications. Without waiting, you might scan the menu before it fully renders, missing aria-expanded states or keyboard trap issues.

• Cross-Browser Coverage: Playwright supports Chromium, Firefox, and WebKit across Windows, macOS, and Linux.
• Performance Impact: Adding accessibility checks typically adds 200-500ms to test execution time, according to Checkly’s benchmarks.
• Adoption: Reddit users report catching dozens of regressions in CI pipelines that manual testing missed over months.

The setup requires more effort than Lighthouse. You need to install both packages (`npm install @playwright/test @axe-core/playwright`) and configure your test files. But once set up, it runs automatically every time you push code. This shifts left approach prevents broken accessibility from reaching production.

Building Your Accessibility Workflow

No single tool solves accessibility. You need a layered strategy. Think of it like security: you have firewalls, antivirus, and physical locks. Similarly, you need different tools for different stages of development.

Start with axe DevTools during local development. Get immediate feedback as you write components. Fix issues before they pile up. Then, run Lighthouse before committing. Use it as a quick sanity check to ensure you haven’t broken basic standards like color contrast or image alternatives.

Finally, integrate Playwright with axe-core into your CI/CD pipeline. This is your automated gatekeeper. It ensures that new features don’t break existing accessibility. Configure it to fail builds if critical violations appear. Ignore minor style issues that don’t impact usability to avoid noise.

Remember the limitations. Automated tools catch about 30% of issues. The rest requires manual testing. You still need to test with actual screen readers like NVDA or VoiceOver. You still need to navigate with a keyboard alone. Automation handles the technical violations; humans handle the experience.

Common Pitfalls to Avoid

Even with the best tools, teams stumble. Here are the most common mistakes I see in vibe-coded projects:

Ignoring False Positives: Modern frameworks generate dynamic IDs and classes. Axe-core might flag these as duplicates or invalid. Learn to configure `.disableRules(['duplicate-id'])` for known safe patterns. Don’t just silence the rule globally; be specific.

Relying on Scores Alone: A perfect Lighthouse score doesn’t mean accessible. It means no *automated* violations were found. Always pair scores with manual review.

Neglecting Timing: In SPAs, scanning too early yields incomplete results. Always wait for key elements to load before running accessibility checks in Playwright.

Skipping Keyboard Navigation: Tools can check if tab order exists, but not if it makes sense. Test your flow manually. Does the focus jump randomly? Can you escape modals with Escape?