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

You built a stunning interface. The gradients pop, the animations are buttery smooth, and it looks exactly like the design mockup. But can someone using a screen reader actually navigate it? If you’re working with vibe-coded frontends-those highly dynamic, visually driven interfaces often built with modern frameworks like React or Svelte-you know the struggle. Visual appeal doesn’t equal accessibility. In fact, WebAIM’s recent survey found that 96.3% of home pages have detectable accessibility issues. That’s not just a stat; it’s a warning light flashing on your dashboard.

The good news? You don’t need to guess. Three tools dominate the conversation: axe-core, Lighthouse, and Playwright. Each plays a different role in keeping your code compliant with WCAG standards. Let’s break down how they fit into your workflow, where they shine, and where they’ll leave you hanging.

Why "Vibe-Coded" Interfaces Break Accessibility

Modern frontend development prioritizes user experience through complex JavaScript interactions. Think custom dropdowns, modals that trap focus, and infinite scroll lists. These features look great but often lack semantic HTML structure. A developer might use a <div> with an onClick handler instead of a <button>, breaking keyboard navigation. Or they might rely on CSS for visual cues that screen readers ignore.

Automated testing tools help catch these errors early. They inject scripts into your DOM to check attributes, contrast ratios, and structural integrity. But no single tool does it all. Understanding their specific architectures helps you choose the right one for the job.

Axe-Core: The Deep-Dive Engine

axe-core is the industry standard for automated accessibility checks. Created by Deque Systems in 2015, this open-source JavaScript library powers many other tools, including Lighthouse. It operates by analyzing the DOM against WCAG 2.0, 2.1, and 2.2 rules. With version 4.7.2, it includes 58 built-in rules covering everything from color contrast (requiring a minimum 4.5:1 ratio) to ARIA attribute validity.

What makes axe-core powerful is its speed and depth. It processes scans in 150-300ms, making it ideal for integration during active development. However, it’s not magic. It catches about 30-40% of total accessibility issues because it can’t judge context. For example, it can tell you an image has alt text, but it can’t tell you if that alt text accurately describes the image. That still requires human judgment.

Lighthouse: The Quick Audit

If you’ve ever opened Chrome DevTools, you’ve seen Lighthouse. Developed by Google Chrome Labs, it’s an open-source tool that audits performance, SEO, and accessibility. Its accessibility module uses axe-core under the hood, which means it inherits axe’s rule set but packages it differently.

Lighthouse generates a score from 0-100, with 90+ considered "good." This scoring system is intuitive for stakeholders who want a quick health check. You can run it directly in the browser, via CLI, or as a Node module. The main drawback? It’s heavily optimized for Chrome. While Firefox support exists, it’s partial. Also, Lighthouse only reports automatically detectable issues. In one benchmark, it detected only 3 out of 9 test issues compared to axe-core’s 7, largely because it filters out warnings that require manual review.

Playwright: The Automation Gatekeeper

Playwright, introduced by Microsoft in 2020, is primarily a cross-browser automation framework. But its integration with axe-core via the @axe-core/playwright package turns it into a robust accessibility testing solution. Unlike Lighthouse, which runs once per page load, Playwright allows you to embed accessibility checks within end-to-end tests.

This is crucial for Single Page Applications (SPAs). Dynamic content loading can cause false negatives if tests run before elements render. Playwright lets you wait for specific elements-like a navigation menu flyout-to appear before scanning. This precise timing control ensures your tests reflect the actual user experience. Plus, it supports Chromium, Firefox, and WebKit, giving you true cross-browser compatibility.

Comparing the Tools: Which One Do You Need?

Choosing between these tools isn’t about picking a winner; it’s about fitting them into your pipeline. Here’s how they stack up:

Notice the pattern? Axe-core is your debugger. Lighthouse is your report card. Playwright is your security guard, stopping bad code from reaching production.

Common Pitfalls in Vibe-Coded Apps

Even with these tools, developers face hurdles. One big issue is false positives. Modern frameworks like React and Tailwind CSS use dynamic class naming, which can confuse axe-core. For instance, valid ARIA attributes might be flagged as errors due to hydration mismatches. Another challenge is timing. If your app loads data asynchronously, running accessibility tests too early results in incomplete scans.

To fix this, use Playwright’s waitFor methods. Before running an accessibility scan, ensure critical UI elements are visible. You can also configure axe-core to ignore specific rules that don’t apply to your design system, such as duplicate IDs generated by component libraries.

Building a Practical Workflow

Don’t try to replace manual testing with automation. Automated tools catch syntax errors; humans catch logic errors. Here’s a recommended workflow for teams building vibe-coded frontends:

• During Development: Install the axe DevTools browser extension. Run scans on individual components as you build them. This gives immediate feedback without slowing down your coding flow.
• Before Commit: Run Lighthouse locally. Check the accessibility score. If it drops below 90, investigate the violations. This acts as a lightweight gate before code enters the repository.
• In CI/CD Pipeline: Integrate Playwright with axe-core. Set up tests to run on every pull request. Configure the pipeline to fail if new accessibility violations are introduced. This prevents regressions over time.

Experts like Marcy Sutton emphasize that while automated tools catch only about 30% of issues, their real value lies in preventing regressions. By integrating them into your CI/CD pipeline, you create a safety net that grows stronger with each release.

Final Thoughts: Don’t Rely on Scores Alone

A perfect Lighthouse score doesn’t guarantee an accessible site. Adrian Roselli warns that relying on a single metric is misleading. Similarly, Léonie Watson notes that automated tests create a false sense of security. Use these tools as aids, not oracles. Combine automated checks with manual keyboard navigation and screen reader testing. Your users will thank you for it.