DevAlly
AI powered accessibility compliance for teams who ship fast
313 followers
AI powered accessibility compliance for teams who ship fast
313 followers
Whether you’re starting or scaling your accessibility compliance program, DevAlly helps product teams automate and streamline compliance under EAA, ADA and Section 508.
This is the 2nd launch from DevAlly. View more
DevAlly MCP
Launching today
DevAlly MCP connects your accessibility compliance data to any AI assistant that supports MCP: Claude, Claude Code, Cursor, ChatGPT, Codex and many more.
Ask "show me all critical issues on checkout" or "what is the fix for DEV-2487" and get the WCAG criterion, the offending code, and the recommended fix, without leaving your editor.
Triage issues, trigger audits, and build reports by asking. Available on the Growth and Compliance plans, OAuth sign-in, connected in under 60 seconds.
Free Options
Launch Team
DevAlly
Hi Product Hunt 👋 Cormac here, co-founder at DevAlly.
We built the DevAlly platform so product and engineering teams could find and fix accessibility issues before they ship, but one thing kept coming up. The context sat in our dashboard, but product teams wanted it as part of their AI workflow.
The DevAlly MCP closes that very gap. Connect it once to Claude, Claude Code, Cursor, or any MCP client, and now you can ask things like "what critical issues are open on our product?" or "what is the fix for issue DEV-2487?". The WCAG criterion, the offending code, and the recommended fix are now available directly in your workflow. You can trigger audits and build reports the same way, by simply asking.
With the EAA in force in Europe and ADA and Section 508 obligations growing in the US, accessibility compliance is a hard requirement. The teams staying on top of it, are tackling it proactively with every release.
It connects in under a minute and is available on our Growth and Compliance plans. We would love your feedback, especially on what you want it to handle. We're reading every comment today. What will you ask it first?
Would love to see a Chrome extension that flags accessibility issues right in our PRs before they ever get merged. That kind of in-context feedback would make the whole compliance flow way less of a chore for our dev team.
DevAlly
@hlyavzf8 Love this! Good news is the thing you're picturing basically already exists, in a different form, and it isn't ours, so treat this as a personal recommendation and not a pitch.
For flagging issues in the PR before it merges, I'd point you at GitHub's own Accessibility Scanner action (published by the github org itself). It runs on each PR and comments issues right in the diff, which is the in-context feedback you're after:
https://github.com/marketplace/actions/accessibility-scanner
To catch things even earlier, if you're on React/JSX, I'd add eslint-plugin-jsx-a11y as a pre-commit hook (husky + lint-staged) so problems show up while devs are writing the code.
Worth being straight about scope though: tools like these only decide what a machine can decide, which in accessibility is about a third of the criteria (contrast, missing alt, invalid ARIA, the mechanical stuff). A linter can tell you alt text exists, not whether it's meaningful. The other two-thirds, things like focus order and whether your labels actually make sense, need human judgment by nature, not because the scanners are immature.
That gap is exactly why we're building DevAlly. The commit and PR checks cover the third a machine can settle. The harder part is turning both the machine-checked and the human-judged findings into a conformance claim you can defend when procurement or a regulator pulls on it, taking a team from zero to that claim without the automated and manual passes duplicating each other, and then keeping it defensible long into the future.
One thing I'd love to see is a built-in remediation suggestions panel right inside the scan results, so devs can click an issue and get copy-paste code snippets or config fixes tailored to their framework. Right now the report flags problems but leaves a lot of interpretation work for engineers.
DevAlly
@recep728172 Great point and thanks for the suggestion! The interpretation gap between "here's what's wrong" and "here's the fix" is real, and it's exactly why we built the MCP.
Connect DevAlly's MCP to Claude Code, Cursor, or whatever agent you use, and your scan results land directly in your editor with full context: the element, the criterion, why it fails. Because the agent is sitting in your actual repo, the fix comes back written against your real components and framework and not a generic snippet you have to adapt, but a change ready to review and commit. The report flags the problem; the DevAlly MCP hands your tools everything they need to fix it.
Would love to hear how it goes if you try it on an issue from your scan.
What made an MCP server the right form factor, and do you think this is where most compliance tooling is headed?
DevAlly
@overpath_eoin Great question!
On form factor: honestly, we didn't pick MCP to be on-trend, the work already had that shape. Whether you're a developer fixing an issue, a compliance lead asking where you stand, or a PM pulling a status report, it's the same loop: ask in context, get the data, take an action. The tax in most compliance tooling is context-switching into yet another dashboard to do that, and MCP removes it. Everyone stays in the tool they already work in, whether that's Claude Code, Cursor, Codex, or just Claude.ai, and the agent reaches our data for them. The remediation side is the sharpest example: a scanner that only reports is half a tool, but when an issue lands in the same agent that has your codebase, it can actually be fixed, not just logged.
from an implementation standpoint, It's a thin, OAuth-scoped surface over our public API, because we don't need to own the agent. The customer brings the model they trust, and that model already knows their codebase: the conventions, the rules, how the thing is actually put together. We bring the accessibility knowledge and the grounded context for each issue. Put those together and you get a fix that fits your existing patterns, a properly integrated change rather than a tacked-on patch that clears the audit but ignores how your code is built.
On where it's headed: partly, I think!
Meeting people in the tools they already use, instead of making them come to a dashboard, is the real shift, and I think most compliance tooling ends up there. But the surface is the easy part to copy. The durable thing is the depth behind it, the knowledge and the record that make the answers trustworthy. An MCP over a thin tool is still thin. So my bet is continuous and agent-accessible becoming the norm, with the winners decided by what sits behind the surface, not the protocol itself.
Roamr for Friends
What happens when the assistant is wrong? Is there a path back to the source in the DevAlly UI to verify?
DevAlly
@stephen_dooley1
Good question, and honestly it's the part we care most about getting right.
Short version: the assistant is a lens over the record, never the record itself. The DevAlly app is the system of record, and the MCP reads from that same source, so the tools only ever return real rows and real errors. Ask for something that isn't there, or that you're not entitled to, and you get a clear error rather than a guess. The model sitting on top isn't infallible, certain models still summarise clumsily or overreach, and we don't pretend otherwise. What we do guarantee is that everything it tells you traces back to a record you can open, so a wrong answer is always one click from being caught, not buried.
That path back to source is the point. Every issue and case carries a stable key, the same one you see in the app, so whatever the assistant cites you can pull straight up. Underneath each finding is the actual evidence: the page URL, the element selector, the element and page screenshots, and the detection history across audits. Reports come back as the real signed document, not a description of one. So checking the assistant isn't "take its word for it," it's open the row and look at the screenshot.
And it doesn't stop at reading. When you fix an issue the assistant surfaced and ship the PR, the loop closes with a re-audit: an automated re-scan confirms the finding is actually resolved and catches the regressions it can see, while the judgment-based criteria get a human recheck. So a fix isn't trusted because the assistant proposed it, it's trusted because the next audit says the issue is gone and nothing else broke. That's what keeps what the assistant tells you honest against what's actually true in your product.
I like that the MCP surfaces the WCAG criterion alongside the relevant code and remediation context. Compliance tools are most useful when they help developers understand why something is an issue, not just that it failed.
DevAlly
@varun1jan
Thanks Varun, that's exactly the line we're trying to walk.
The criterion is doing more than labelling the failure, too. It's the same axis the conformance report is built on, one row per success criterion, so the "why" a developer reads at fix-time is the same requirement a compliance lead signs off on later. That's half the reason we anchor on the SC rather than a tool-specific rule ID: the dev, the PM, and whoever has to defend the claim are all looking at the same requirement, backed by the evidence the DevAlly platform collects: detected / logged against that criterion, resolved by a specific change, then confirmed cleared in a later human or automated audit.
And to your point about understanding the why, it compounds. Once someone sees why 1.4.3 fails and what actually resolves it, they tend to stop shipping that whole class of issue, which is worth more over time than any single fix.
DevAlly
Darren here, CTO. A few notes for the builders.
It's a remote MCP server on the Streamable HTTP transport (with an SSE fallback for older clients). Auth is the standard MCP OAuth flow: OAuth 2.1 with PKCE, protected-resource metadata (RFC 9728), and dynamic client registration, so there are no API keys to generate or rotate. You sign in, pick your org, and the client gets a scoped token.
Because it's a proper remote server, the current clients connect straight to the URL, no mcp-remote bridge in the middle. Claude.ai and Claude Desktop go through their custom-connector UI; Claude Code and Cursor just take the URL in the MCP config. (mcp-remote still works if you're on a client that only speaks stdio.)
Tokens carry per-resource scopes (read or write across workspaces, products, audits, issues, workflows, and reports), so it only ever sees what your DevAlly account can, bounded by your org.
Happy to go deep on the auth or tool design if anyone wants it!