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:
| Feature | axe-core | Lighthouse | Playwright + axe-core |
|---|---|---|---|
| Primary Use Case | Deep analysis during development | Quick audits and scoring | CI/CD integration and regression testing |
| Detection Rate | High (93.3% in benchmarks) | Moderate (83.3% in benchmarks) | High (matches axe-core) |
| Cross-Browser Support | All major browsers | Chrome-centric | Chromium, Firefox, WebKit |
| Integration Effort | Low (library injection) | Very Low (built into Chrome) | Medium (requires test setup) |
| Best For | Debugging specific components | Pre-commit checks and stakeholder reports | Automated gates in CI pipelines |
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.
Can I use just Lighthouse for accessibility compliance?
No. Lighthouse is excellent for quick checks and awareness, but it only detects automatically identifiable issues. It misses context-specific problems like poor alt text quality or logical reading order. For full compliance, combine it with deeper tools like axe-core and manual testing.
Is Playwright better than Cypress for accessibility testing?
Both can work, but Playwright offers superior cross-browser support (Chromium, Firefox, WebKit) compared to Cypress’s limited browser options. Additionally, Playwright’s handling of dynamic content and waiting mechanisms makes it more reliable for SPAs where timing affects accessibility scans.
How long does it take to set up axe-core with Playwright?
Typically 15-30 minutes for basic setup. You install the packages (npm install @playwright/test @axe-core/playwright) and write a simple test script. Complex configurations, such as ignoring specific rules or handling async content, may take longer depending on your application's complexity.
Does axe-core work with all JavaScript frameworks?
Yes, axe-core is framework-agnostic because it analyzes the final DOM. However, frameworks like React or Vue may produce dynamic classes or attributes that trigger false positives. You often need to tweak configuration settings to suppress irrelevant warnings related to hydration or virtual DOM updates.
What percentage of accessibility issues can automated tools catch?
According to W3C documentation and industry experts, automated tools like axe-core catch approximately 30-40% of total accessibility issues. The remaining issues involve subjective criteria, such as whether link text is meaningful or if error messages are clear, which require manual human evaluation.
5 Comments
jyotshna Senapati
Oh honey, this is adorable. You think adding a few aria-labels and calling it "vibe-coded" fixes everything? Please. I've seen teams ship garbage because their Lighthouse score was 98 while a screen reader user couldn't even find the submit button. It’s not about tools; it’s about whether you actually care or just want to check a box for your manager. The fact that you’re listing Playwright as if it’s some magic bullet shows you haven’t dealt with flaky CI pipelines in production. Most people don’t have the discipline to maintain these tests, so they just rot until someone gets sued.
Ejike Ugwu
they know what they are doing
its all rigged
why do you think big tech pushes react and svelte so hard
because it breaks accessibility by default
so you need three different tools just to prove your site works
if html was good enough we wouldnt need axe core
they made it broken on purpose so they can sell us the fix
wake up sheeple
Kathleen Johnson
The comparison table is misleading at best. You claim Playwright has "High" detection rates matching axe-core, but that ignores the latency overhead of running full E2E suites for every PR. In my experience, teams skip these checks when deadlines loom, rendering the "security guard" metaphor useless. Furthermore, stating that Lighthouse detects only 3 out of 9 issues is cherry-picked data from a specific benchmark without context on the complexity of those test cases. A more rigorous analysis would acknowledge that Lighthouse’s filtering mechanism often hides critical warnings that require manual review, creating a false sense of compliance for junior developers who trust the green score blindly.
Kathy Mccoy
This is such a helpful breakdown! I love how you emphasized that automated tools are just aids and not replacements for human testing. That reminder about Marcy Sutton really hit home for me. I’ve been guilty of relying too much on Lighthouse scores, thinking a 100 meant I was done. But realizing that keyboard navigation and actual screen reader usage are where the real bugs hide changes everything. Keep sharing these practical workflows, they make a huge difference for folks trying to build inclusive interfaces without burning out!
Sundaraiah Kollipara
i wonder though
if we focus so much on catching errors after the fact
are we not missing the root cause
maybe the issue is that we treat accessibility as a checklist rather than a design principle
when you build with empathy first
you dont need as many tools to tell you if a button is a button
it should be intuitive
but maybe thats just idealism
in a world of tight deadlines and complex frameworks
tools like playwright become necessary crutches
the question is
does relying on crutches weaken our ability to walk naturally
or does it let us run faster
hard to say
but i appreciate the detailed look at the tradeoffs here