DEV Community

Gagan Singh
Gagan Singh

Posted on

How I Used Cypress and Claude to Find and Fix Accessibility Issues

A few weeks ago I started exploring the new accessibility features in Cypress Cloud. I did not want to write another setup guide. I wanted to show something real, something you could actually follow and use on your own projects.

So I put together a dummy app, ran Cypress against it, and connected Claude via the Cypress Cloud MCP. What came out of that was a complete detect, analyze, fix, and verify loop that I think is genuinely useful for any team that cares about accessibility.

Here's exactly what I did and what I found.

The Dummy App

The dummy banking portal login page used for the demo

To make the demo concrete and relatable, I built a simple dummy app that looks like an online banking portal. It has two pages: a login page and an account dashboard with a transaction table.

I chose this kind of app because most developers have seen one, and the accessibility stakes are immediately obvious. People rely on financial apps to check balances, pay bills, and manage their money. If the app isn't accessible, real users are locked out. The dummy app is just there to make the workflow clear. The same approach works for any project.

The Workflow

The whole thing runs in three steps:

  1. Detect Run Cypress tests that visit the pages and record the results to Cypress Cloud. No extra plugins needed. Cypress Cloud scans for accessibility violations automatically in the background on every recorded run.
  2. Analyze Ask Claude, via the Cypress Cloud MCP, what failed and why. Claude pulls the full accessibility report directly from Cypress Cloud and ranks the issues by severity.
  3. Fix and Verify Apply the fixes to the code and record another run. Ask Claude to confirm the report is clean.

What Cypress Cloud Found Automatically

On the first recorded run, Cypress Cloud detected 4 failing accessibility rules across both pages with no plugin or extra configuration required:

  • color-contrast (serious): text did not meet WCAG contrast requirements
  • landmark-one-main (moderate): pages were missing a main landmark
  • page-has-heading-one (moderate): pages were missing a level one heading
  • region (moderate): page content was not wrapped in landmark regions

Cypress Cloud showing 81% score and 4 failed rules on the first run

That's an 81% accessibility score right out of the gate, with zero setup beyond recording the run.

Where Claude Comes In

After the run was recorded, I opened Claude Desktop and asked it to pull the accessibility report for that run via the Cypress Cloud MCP. Claude returned the full report ranked by severity, explained what each rule meant, and told me which issue to fix first.

You're not just getting a list of rule IDs. You're getting context, prioritization, and a clear starting point, all without leaving your workflow. That's what made this feel genuinely useful rather than just a cool demo.

The Fixes

Once the issues were clearly identified, the changes were straightforward:

  • Added proper labels to form inputs on the login page
  • Wrapped page content in a main landmark element
  • Added a level one heading to both pages
  • Fixed text color contrast to meet WCAG AA requirements
  • Added alt text to images
  • Added an aria-label to the navigation element

After the Fixes

Cypress Cloud showing 100% accessibility score after the fixes were applied

I applied the fixes, recorded another run, and asked Claude to pull the new accessibility report. The result: a 100% accessibility score with 0 failed rules across both pages. Claude confirmed it was clean.

The thing that stood out was how little effort it took once the workflow was in place. Cypress Cloud handled the scanning, Claude handled the analysis, and I handled the fixes. Each tool doing what it's good at.

What I Took Away From This

Accessibility testing doesn't have to be a separate process bolted on at the end of a sprint. With Cypress Cloud running checks automatically on every recorded run, and Claude surfacing the results via MCP, it becomes part of the normal development loop.

The dummy banking app was just a vehicle to make the workflow concrete. The same approach works for any application where real users depend on your code working correctly for everyone.

If you're experimenting with accessibility testing in your own CI pipeline, I'd love to hear how you're approaching it. Drop a comment below.

Top comments (0)