Accessibility, But Make It Continuous

I used to treat accessibility as a separate audit phase. That model is too slow and usually too late.

I would usually discover problems right before release, when touching markup, CSS, or interaction patterns feels like defusing a bomb with a deadline. Even when issues were straightforward, the feedback cycle was painful: open report, decode rule IDs, hunt elements, patch, rerun, repeat. Not difficult work, just expensive context switching.

What works better is an agentic loop where an AI agent runs tests in Cypress Cloud, queries accessibility findings through Cypress MCP, translates violations into concrete code changes, and then applies fixes and reruns until the report improves.

This is the key shift: accessibility stops being a once-a-quarter panic and becomes a continuous engineering loop.

More importantly, the work becomes calmer. Instead of pin balling between dashboards, terminals, and source files, I stay in one flow while the agent handles the noisy parts.

The setup was intentionally simple

I created two pages, with index.html as the clean baseline and nightmare.html as the intentionally broken page.

I wrote only two tests that visit both pages.

 describe('Visit both demo pages', () => {
  it('visits the accessible page', () => {
    cy.visit('index.html');
    cy.contains('Accessible Meadow').should('be.visible');
  });

  it('visits the nightmare page', () => {
    cy.visit('nightmare.html');
    cy.contains('Welcome To The Maze').should('be.visible');
  });
});

That is enough. If the pages are visited in a recorded run, Cypress Accessibility does the analysis in Cloud.

The simplicity here is intentional. I wanted to prove the value is not in fancy test choreography. The value is what happens after the results land.

The stack that makes this work

The workflow combines Cypress Cloud for run orchestration, Cypress Accessibility for rule detection and scoring, Cloud MCP for machine-readable access to findings, and an AI coding agent for diagnosis, patching, and verification. Each piece matters, but the multiplier is the agent: MCP gives it structured truth, and the agent turns that truth into edits.

Without MCP, accessibility data is mostly something humans read. With MCP, it becomes something software can act on. That one change is the difference between an assistant that nods and an agent that ships fixes.

How I ran tests in Cloud

My script records every run:

{
  "scripts": {
    "test": "npx cypress run --record --key <YOUR_RECORD_KEY>"
  }
}

Then I run:

npm run test

That produces a Cloud run with a run number the agent can immediately query.

From there, I stop doing manual collection work. No screenshot scavenger hunt, no dashboard archaeology. The run metadata and accessibility output are already there, ready for the agent to consume.

How the agent queried findings through MCP

The AI agent talks to the Cloud MCP server through native MCP tools such as cypress_get_runs to identify the latest Cloud run, cypress_get_accessibility_report to retrieve rule-level findings, and cypress_get_accessibility_rule_failures to drill into failing elements.

The important point is that the agent receives structured output directly, not a blob of human-only context.

At that point, the flow becomes fully autonomous: the agent detects the newest run, pulls the full accessibility findings, maps each rule to concrete code edits, patches files, reruns tests, and compares deltas before repeating.

In practice, this feels like handing off a tightly scoped mission. I ask for a remediation pass and get concrete file changes tied directly to reported violations, followed by verification from a fresh Cloud run.

What the agent can do with the report

The agent can read rule IDs and impact levels, then convert them into deterministic fixes. For example, when it sees label or select-name, it can add explicit labels and connect them to control IDs; when it sees image-alt, it can add meaningful alt text; when it sees page-has-heading-one, it can enforce one clear <h1> per page; when it sees landmark-one-main or region, it can add semantic landmarks and structure; and when it sees color-contrast, It can adjust foreground and background values to pass thresholds.

The crucial part is that the same agent that reads the issue can patch it immediately.

That is where MCP changes the game: debug and fix become one continuous agent action, not two separate human chores.

What this looks like in real work

On a normal feature branch, I can treat accessibility as a continuous quality signal rather than a late gate. I run the tests, the agent reads the report, and I get a focused patch proposal in minutes. Then I review the diff the same way I would review any other code change: does the markup make sense, are labels accurate, does keyboard behavior remain intuitive, and is visual design still aligned with the product language?

This balance matters. The agent handles speed and consistency; I keep ownership of intent and experience.

Why this feels different from old accessibility workflows

In a traditional flow, I run a scan, export a report, manually triage, manually patch, and retest later. In the agentic Cypress flow, that sequence collapses into a tight loop: run, query, patch, rerun, compare deltas, repeat now. That compression is what makes accessibility debt shrink instead of quietly compounding.

When feedback loops are short, teams fix more. When loops are long, teams postpone. The agentic model changes that default behaviour.

Accessibility is no longer the hurdle it used to be

For a long time, accessibility felt like the kind of thing you either had to hire a specialist for or quietly pushed to the next sprint. It carried weight, complexity, and a reputation for being hard to do consistently.

This workflow changed that perception for me. Two HTML pages, two Cypress tests, a Cloud project, and an AI agent with access to the MCP server. That is genuinely all it took to get a continuous, actionable accessibility feedback loop running.

And the agent is useful beyond the clean cases too. When a violation traces back to missing content in a CMS rather than missing code, it can flag that the real fix belongs at the data source, not in a runtime bandaid. That is a more honest and durable solution than hardcoding a fallback at render time.

The same applies when the offending component lives in a design system your team does not own. Rather than patching something you should not be overriding, the agent can produce a scoped handoff for that team instead: here is the failing rule, here is the affected component, here is what needs to change. The agent moves fast enough to triage correctly, not just reflexively.

The setup is easy. The work the agent does is real. And the gap between "we should fix this" and "it's fixed" has never been smaller.