Accessibility Prover MCP. Audit semantic structure & focus before building
Gemini Works with every AI agent you already use
…and any MCP-compatible client
Just plug in your AI agents and start using Vinkius.
Accessibility Prover: Validates UI code against WCAG 2.2 AA and EAA 2025 standards. It forces AI agents and developers to check for semantic HTML, proper keyboard focus, color contrast, and screen reader readiness *before* the component is built.
This tool checks for common failures like 'div soup' and motion risks, guaranteeing a higher level of user inclusion.
What your AI agents can do
Validate accessibility
Runs a structured check to confirm semantic HTML, keyboard navigation, contrast ratios, ARIA annotations, and motion media queries are all correct for a given component.
Determines if the component uses correct HTML5 tags (like <button> or <nav>) instead of relying on non-semantic div elements.
Confirms that every interactive element is reachable via the keyboard, that focus indicators are visible, and that focus is correctly contained within modals.
Calculates the contrast ratio between text and background colors, flagging any combinations that fall below the required WCAG 2.2 AA standards.
Checks for necessary ARIA attributes, proper alt texts on images, and correct association between form labels and inputs.
Ensures that complex animations and transitions respect the user's operating system preference for reduced motion, preventing potential seizures or vertigo.
Ask AI about this MCP
Supported MCP Clients
Gemini Waiting for input…
019e599avalidate accessibility
Runs a structured check to confirm semantic HTML, keyboard navigation, contrast ratios, ARIA annotations, and motion media queries are all correct for a given component.
Choose How to Get Started
Build a custom MCP for your own tools, or connect a ready-made integration from our catalog.
Build Your Own
Turn any API into an MCP. Import a spec, define Agent Skills, or deploy with MCPFusion.
- Import from OpenAPI, Swagger, or YAML specs
- Create Agent Skills with progressive disclosure
- Deploy to edge with MCPFusion framework
- Built in DLP, auth, and compliance on every call
- Real time usage dashboard and cost metering
- Publish to catalog or keep private
Make Your AI Do More
Start with Accessibility Prover, then connect any of our 4,700+ other servers whenever your AI needs more. One click, no limits.
- Use this MCP plus 4,700+ others, all in one place
- Add new capabilities to your AI anytime you want
- Every connection is secured and compliant automatically
- Track usage and costs across all your servers
- Works with Claude, ChatGPT, Cursor, and more
- New servers added to the catalog every week
What you can do with this MCP connector
Your AI client uses the validate_accessibility tool to check components against WCAG 2.2 AA and EAA 2025 standards. It makes sure that front-end developers and your agent check for semantic HTML, proper keyboard focus, color contrast, and screen reader readiness before you write component code. This tool catches common issues like 'div soup' and motion risks, guaranteeing better user inclusion.
It checks if the component uses correct HTML5 tags, like <button> or <nav>, instead of relying on non-semantic div elements. It confirms that every interactive element is reachable using the keyboard, that focus indicators are visible, and that focus stays contained inside modals. It calculates the contrast ratio between text and background colors, flagging any combinations that fall below the required WCAG 2.2 AA standards.
It checks for necessary ARIA attributes, proper alt texts on images, and correct association between form labels and inputs. It ensures complex animations and transitions respect the user's operating system preference for reduced motion, preventing potential seizures or vertigo.
How Accessibility Prover MCP Works
- 1 Submit the component code or UI specification to the
validate_accessibilitytool. This tool simulates user interactions, checking the component against five required accessibility pivots. - 2 The tool analyzes the code for issues—like non-semantic HTML, poor contrast, or missing ARIA labels—and returns a detailed report of every barrier found.
- 3 Fix the reported issues in your code. The tool requires passing all five checks before marking the component as compliant.
The bottom line is that the tool forces you to fix accessibility problems in your code before you deploy the component.
Who Is Accessibility Prover MCP For?
Product designers and front-end engineers who treat accessibility as a feature, not an afterthought. It's for the dev team that gets tired of fixing legal compliance issues right before a major release. These are people who need to ship high-quality, inclusive UIs that don't expose the company to risk.
Uses validate_accessibility to ensure every new component meets semantic HTML and contrast standards before merging code.
Reviews the validate_accessibility report to fix layout issues, ensuring focus order is logical and color contrast is sufficient for all users.
Runs the tool against the component library to confirm keyboard navigability and screen reader readiness across all user flows.
What Changes When You Connect
- Guarantees Compliance: Passing the
validate_accessibilitytool means your component meets WCAG 2.2 AA standards. This directly reduces legal risk exposure and speeds up compliance sign-off. - Eliminates Div Soup: The tool forces the use of native HTML5 elements (like
<button>and<nav>), preventing developers from using non-semanticdivstructures that confuse screen readers. - Checks Focus Traps: It verifies that all interactive components are reachable and that focus remains correctly contained when a modal dialog opens, solving a major keyboard navigation failure.
- Enforces Visual Contrast: By demanding numerical contrast ratios (e.g., 4.5:1), the tool stops developers from using color palettes that make text illegible for users with low vision.
- Protects Motion-Sensitive Users: The
validate_accessibilitytool checks for and flags animations that don't respect theprefers-reduced-motionsetting, keeping the site usable for everyone. - Streamlines QA: Instead of manual audits, running the tool provides an immediate, actionable report on all accessibility barriers, cutting down on testing time.
Real-World Use Cases
Fixing a broken checkout flow
A QA engineer suspects the checkout flow is unusable by screen readers. They run validate_accessibility on the checkout component. The tool flags missing ARIA labels on the payment fields and incorrect tab order. The engineer fixes the labels and re-runs the tool, passing all checks.
Reviewing a complex modal dialog
A developer builds a modal that traps focus poorly. They run validate_accessibility. The tool immediately reports a 'Keyboard trapped' failure, forcing the developer to implement proper focus management before the modal hits production.
Updating an old image gallery
A designer adds a new photo gallery. Before committing, they run validate_accessibility. The tool catches that the images are missing descriptive alt texts and that the color contrast on the captions is too low. The developer adds the required attributes and updates the color palette.
Implementing a new primary action button
A team builds a new 'Submit' button using a custom div click handler. They run validate_accessibility and get a DIV_SOUP verdict. The tool forces them to switch to a native <button> tag and ensure it has a proper focus indicator.
The Tradeoffs
Relying on visual checks
Assuming that because the button looks fine, it works for everyone. A visual check won't spot a 1.3:1 contrast ratio or a keyboard focus trap failure.
→
Always run validate_accessibility. The tool measures color contrast ratios and simulates keyboard focus, giving you objective data on true compliance.
Using custom divs for interactivity
Building an element that looks like a button but is just a <div onClick={...}>. This fails because the element lacks native focus and semantic meaning.
→
Use validate_accessibility. The tool enforces the use of native semantic tags like <button> for actions, resolving the DIV_SOUP issue.
Ignoring user preferences
Implementing smooth, full-screen animations that cause motion sickness. This is bad for users who set prefers-reduced-motion.
→
Run validate_accessibility. The tool checks for and enforces media queries that respect the user's motion preferences, keeping the site safe for everyone.
When It Fits, When It Doesn't
Use this if your project requires strict, verifiable compliance with WCAG 2.2 AA standards and needs to prove accessibility before deployment. You must run validate_accessibility on every component and user flow. Don't use it if you're just building a prototype for internal viewing; you need the strict checks it provides. If your primary goal is just basic styling, use a standard linter. If your goal is guaranteed inclusion, use this tool.
Independent Platform Disclaimer: Vinkius is an independent platform and is not affiliated with, endorsed by, sponsored by, verified by, or otherwise authorized by Accessibility Prover. All third-party trademarks, logos, and brand names are the property of their respective owners. Their use on this website is strictly for informational purposes to identify service compatibility and interoperability.
VINKIUS INFRASTRUCTURE
Cloud Hosted
Managed infra
V8 Isolated
Sandboxed per request
Zero-Trust Proxy
No stored credentials
DLP Enforced
Policy on every call
GDPR Compliant
EU data residency
Token Compression
~60% cost reduction
Works with Claude, ChatGPT, Cursor, and more
The Model Context Protocol standardizes how applications expose capabilities to LLMs. Instead of operating in isolation, your AI gains direct access to external platforms, live data, and real-world actions through secure, standardized connections.
This server provides 1 capabilities that interface natively with Claude, ChatGPT, Cursor, and any MCP client. No middleware. No custom integration required.
Available Capabilities
Making sure your UI works for everyone shouldn't be a guessing game.
Manually testing accessibility is slow. You test the happy path, the standard browser, and the ideal color contrast. You miss the edge cases: the focus trap when a modal opens, or the subtle color contrast failure that only appears on a specific screen.
With Accessibility Prover, your agent runs a full audit. It checks semantic HTML, measures the contrast ratio, and simulates the keyboard flow. You get a definitive pass/fail verdict before you even write the component code.
The Accessibility Prover MCP Server: Audit semantic structure & focus
You no longer have to coordinate three different specialists—the color expert, the keyboard tester, and the screen reader specialist—to validate one feature. The tool consolidates all five decision pivots into one actionable report.
It makes compliance a predictable, measurable step in your workflow. You don't just hope it's accessible; the tool proves it.
Common Questions About Accessibility Prover MCP
How does the Accessibility Prover MCP Server use the `validate_accessibility` tool? +
The validate_accessibility tool simulates a user journey across your component. It checks semantic HTML, keyboard focus, contrast ratios, and ARIA labels. It tells you exactly what needs fixing before you commit the code.
Is Accessibility Prover better than standard linters? +
Yes. Standard linters check static code. This tool simulates dynamic user interaction (like focus trapping or color contrast under specific conditions), giving a much deeper, behavioral audit.
Does the `validate_accessibility` tool handle WCAG 2.2 AA? +
Yes, it is designed to validate against WCAG 2.2 AA and EAA 2025 standards. It checks all the necessary pivots, including the 4.5:1 contrast minimum.
Can I use Accessibility Prover to check my whole website? +
The tool is designed for components and complex views. You feed it a single, high-traffic component or a specific user flow, which provides the most actionable and measurable results.
How does the `validate_accessibility` tool handle semantic HTML structure? +
It forces the use of correct semantic tags. The tool rejects designs that use nested div structures for components like buttons or navigation. You must use native elements like <button> or <nav> instead.
What happens if the `validate_accessibility` tool finds a contrast issue? +
The tool returns a specific 'CONTRAST_FAILING' verdict. It tells you the exact ratio failure (e.g., 1.3:1) and the minimum WCAG requirement (4.5:1). You must adjust the color pair to pass the check.
Does `validate_accessibility` check for focus traps and keyboard navigation? +
Yes, it validates the keyboard flow. It checks for logical tab order, visible focus indicators, and ensures that components like modals correctly trap focus when active. You'll need to fix these issues before building.
Is the `validate_accessibility` tool limited to single components? +
No, it checks complex components and entire views. You call it once per UI view or complex component. It provides a structured reflection on the entire user experience flow, not just isolated elements.
Why does the tool reject divs with click handlers? +
Divs lack native keyboard interactivity, focusability, and ARIA roles. Using a native or tag ensures the element works correctly for keyboard-only and screen reader users without complex custom JavaScript.
What is a focus trap and when is it required? +
A focus trap constrains tab navigation inside a specific element (like a modal or dialog) so users cannot navigate to underlying page contents while the modal is active. It is required for all dialogs.
Does the tool check hover state contrast ratios? +
Yes. Interactive elements must maintain the minimum contrast ratio of 4.5:1 across all active states, including hover, focus, and active selections, to ensure visibility during interaction.
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.
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.
Use it with your favorite AI tools
Connect this server to Cursor, Claude, VS Code, and more.
More in this category
Parsio
Extract structured data from emails and PDFs automatically with AI-powered parsing templates that learn from your documents.
Basecamp
Keep your team aligned with project discussions, to-do lists, file sharing, and schedules all in one calm workspace.
Join
Manage recruiting, jobs, and candidates via JOIN API.
You might also like
Station F Global Prover
European startups raise half of what American startups raise — and still think locally. One country. One language. One regulatory framework treated as a burden instead of a barrier that protects them. Station F exists because Europe has 450 million consumers, world-class regulation, and an ambition problem. This tool forces five Station F-level axes: global-first strategy, regulation as moat, capital efficiency, ecosystem density, and continental ambition.
Clinical Reasoning Prover
Forces AI to validate clinical treatment plans against US guidelines (AHA, ACC) using real differential exclusion, explicit pharmacokinetics, and objective triage scales instead of subjective descriptors and diagnostic anchoring.
Pricing Strategy Prover
An AI recommended '$29/month per seat' because that is what three competitors charge. No value metric analysis — seat count has nothing to do with value delivered. No WTP research — the price was copied, not discovered. No segmentation — enterprise pays the same as a 3-person startup. No unit economics — CAC was $380 and LTV at $29/month with 14-month retention was $406. LTV/CAC of 1.07x. The company grew revenue 12% while burning 40% of cash on acquisition. This tool forces value metric definition, WTP research, segment pricing, unit economics, and packaging design.
