# Accessibility Prover MCP for AI Agents AI Agent Connect

> Accessibility Prover is a pre-build validation system that forces WCAG 2.2 AA compliance before code is written. It audits semantic HTML, keyboard navigation, contrast ratios (4.5:1 minimum), screen reader compatibility, and motion safety across 5 structured Decision Pivots. Unlike runtime scanners, it catches div soup, missing focus traps, and inaccessible animations during the design phase.

## Overview
- **Category:** productivity
- **Price:** Free
- **Endpoint:** https://edge.vinkius.com/vk_preview_Z4jgihFSGVmVid2ldA4mxeRfY0ki8hZy1vHx94N4/ai-agent-connect
- **Tags:** accessibility-prover, wcag-2-2-aa, eaa-2025, semantic-html, keyboard-navigation, contrast-ratio, screen-reader, reduced-motion, a11y-validation, shift-left-accessibility

## Description

Most front-end work ends up with a mess of nested divs and broken keyboard navigation because it's easier to build it wrong first and fix it later during a manual audit. Accessibility Prover changes that by moving the gate to the very beginning. Instead of letting your AI agent spit out a bunch of divs with click handlers, this Connector forces it to reason through the actual requirements of the web. It checks if you're using the right tags for the right jobs, if a user can actually tab through the menu, and if the colors are readable for people with low vision. It's about making sure the foundation is solid before the house is built. You can find this among the 4,000+ options in the Vinkius catalog to keep your projects compliant with the European Accessibility Act. It stops the div soup and the keyboard traps from ever reaching your repo. You get a clear verdict on whether your UI design actually works for everyone, giving you the confidence to ship without the fear of a legal headache or a failed audit. By validating your specifications before code is written, you save weeks of rework. You don't have to worry about someone being unable to use your app because of a missing label or a low contrast ratio. You get to ship accessible products that actually work for every user.

## Tools

### validate_accessibility
Run a structured audit on a UI specification to check for semantic HTML, keyboard navigation, contrast, and more. It gives you a clear verdict on whether your design meets WCAG 2.2 AA standards.

## Prompt Examples

**Prompt:** 
```
I want to make a close button. It's a div with an X icon and a click event. Is this okay?
```

**Response:** 
```
Verdict: DIV_SOUP.

A `<div>` lacks native keyboard focus, Enter/Space activation, and the implicit 'button' ARIA role. Screen readers announce it as generic text, so users won't know it is interactive.

**Fix:** Replace `<div onclick>` with `<button aria-label="Close dialog">`. Add `focus-visible` styles for keyboard users. Hide the decorative SVG icon with `aria-hidden="true"`.
```

**Prompt:** 
```
Check this button: #4A5568 text on #FFFFFF background. It's for a small label.
```

**Response:** 
```
Verdict: CONTRAST_FAILING.

✗ **contrastCompliant** — Ratio 1.28:1 fails the WCAG 2.2 AA minimum of 4.5:1. The icon is effectively invisible to users with low vision or color deficiency.

**Fix:** Change icon color to #4A5568 (4.62:1) or #374151 (6.33:1) to exceed the 4.5:1 threshold.
```

**Prompt:** 
```
I'm building a notification banner that slides in. How do I make it accessible?
```

**Response:** 
```
Verdict: MOTION_HOSTILE.

✗ **motionRespected** — A 300ms slide animation lacks a `prefers-reduced-motion` check. This can trigger vestibular disorders for some users.

**Fix:** Wrap the animation in `@media (prefers-reduced-motion: no-preference)` or provide a `transition: none` fallback.
```

## Capabilities

### Verify semantic HTML landmarks
The tool ensures you use actual tags like nav and main instead of divs with click handlers.

### Audit keyboard tab orders
It checks that every interactive element is reachable and has a visible focus indicator.

### Calculate contrast ratios
The tool verifies your colors meet the 4.5:1 minimum for standard text.

### Check screen reader labels
It confirms that icon buttons have aria-labels and images have descriptive alt text.

### Validate motion safety
It checks for prefers-reduced-motion overrides to protect users with vestibular disorders.

## Use Cases

### Pre-commit gate for component libraries
An engineer wants to make sure every new button in their library is accessible. They run the tool on the spec to catch issues before the code is even written.

### AI agent guardrail
A developer wants their AI to stop making divs with click handlers. They tell the agent to use the tool to verify every UI component it designs.

### EAA 2025 compliance
A company selling in the EU needs to prove they are following the law. They use the tool to generate a compliance record for every user-facing component.

### Design system audit
A team needs to prioritize a backlog of fixes. They run the tool on their current components to see which ones are blocked versus just degraded.

## Benefits

- Stop div soup early by using validate_accessibility to force semantic HTML landmarks like nav and main.
- Avoid keyboard traps by ensuring every interactive element has a logical tab order and visible focus indicators.
- Guarantee color readability by checking contrast ratios against the 4.5:1 minimum required for WCAG 2.2 AA.
- Make your UI screen reader ready by verifying that icon buttons have aria-labels and images have alt text.
- Protect users with vestibular disorders by forcing prefers-reduced-motion overrides on all animations.
- Reduce legal risk by creating an auditable record of compliance for the European Accessibility Act (EAA 2025).

## How It Works

The bottom line is you catch accessibility bugs during the design phase instead of the production audit.

1. Describe your UI component or layout to your AI agent.
2. The agent calls the validation tool to run the 5 Decision Pivots.
3. You get a structured verdict with specific fixes if any accessibility barriers exist.

## Frequently Asked Questions

**Why does Accessibility Prover reject divs with click handlers?**
A `` has no native keyboard interactivity, no focusability, and no implicit ARIA role. Adding `onclick` creates a visual button that keyboard and screen reader users cannot operate. Native `` elements provide focus, Enter/Space activation, and the 'button' role automatically — no extra JavaScript required.

**What is a focus trap and when is it required?**
A focus trap constrains Tab navigation inside a specific element — typically a modal, dialog, or dropdown — so users cannot navigate to the underlying page while the overlay is active. WCAG 2.4.3 (Focus Order) requires it for all modal dialogs. Without it, a keyboard user can Tab behind the modal into invisible content.

**Does Accessibility Prover check contrast across all interactive states?**
Yes. The contrastCompliant pivot validates foreground/background color combinations across five states: default, hover, focus, active, and disabled. A button that passes contrast in its default state but fails on hover (e.g., light gray text on white) is flagged as CONTRAST_FAILING.

**How is this different from axe-core or Lighthouse?**
axe-core and Lighthouse scan rendered HTML in a browser — they detect violations after the code is built and running. Accessibility Prover validates UI specifications before code is written. It reasons about component behavior, keyboard flows, and interaction states at the design level, catching architectural issues that post-build scanners cannot see because they only inspect the final DOM.

**Can I use Accessibility Prover with an AI coding agent?**
Yes — that is a primary use case. AI coding agents default to div-based layouts because divs are syntactically simpler. Accessibility Prover acts as a guardrail: the agent submits its component specification, the prover validates it against 5 pivots, and the agent receives a structured verdict with specific fixes before writing code.

**What does the European Accessibility Act (EAA 2025) mean for my product?**
Since June 2025, the EAA requires all digital products and services sold in the EU to meet accessibility standards equivalent to WCAG 2.1 AA (with WCAG 2.2 AA as the recommended benchmark). Non-compliance carries fines up to 5% of annual revenue and potential market withdrawal. Accessibility Prover helps demonstrate compliance as a build-time gate, creating an auditable validation record.

**What input format does Accessibility Prover expect?**
Submit each component as structured text covering 5 dimensions: (1) Layout — the HTML elements and hierarchy, (2) Keyboard — tab order, focus indicators, focus traps, (3) Contrast — foreground and background hex values with computed ratio, (4) Screen Reader — alt texts, aria-labels, form-label associations, (5) Motion — animation properties and prefers-reduced-motion handling. The tool reasons about each dimension independently.

**Does Accessibility Prover support WCAG 2.2 AAA?**
The tool validates against WCAG 2.2 AA, which is the legally required level under the EAA 2025 and the practical target for most products. AAA requirements (e.g., 7:1 contrast ratio, sign language interpretation) are not enforced — they are aspirational goals that few products achieve fully.