DevAlly
AI powered accessibility compliance for teams who ship fast
395 followers
AI powered accessibility compliance for teams who ship fast
395 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 3rd launch from DevAlly. View more
DevAlly AI Agent
Launched this week
Describe a user journey in plain English. The DevAlly Agent navigates your app and records a user journey, saving hours of engineering work. The DevAlly platform then audits each stage of journey against the WCAG criterion and suggests fixes for every issue.
Constant changes, requires consistent accessibility monitoring. Our agent does it for you.
Free
Launch Team / Built With
Customer.ioAutomate Messaging Everywhere — Startups Get 12 Months Free
Promoted
Hey Product Hunt!
Cormac here, CEO and co-founder of DevAlly. You might remember us from May, when we launched DevAlly, and July, when we brought accessibility compliance into your editor with our MCP. Thank you for the support both times. It shaped what we built next.
Here's what we kept hearing. Scans are good at checking pages, but users actually perform journeys. They sign up, check out, book an appointment, reset a password. The barriers that stop a disabled person from finishing a task commonly live between the pages. Think of the modal that traps keyboard focus, the error message a screen reader never announces, the session timeout nobody can extend, or the payment step that only works with a mouse.
WCAG already recognises this. Its conformance rules say that if a page is part of a process, every step of that process has to conform. A checkout that's 90% accessible is a checkout someone can't finish. Yet these flows are the least tested part of most products. Testing them has meant stepping through every click by hand, or writing scripted tests that break every time the UI changes. So teams test the homepage and a handful of templates, and the journeys that matter most go unchecked.
That's what we set out to change with DevAlly Agent and natural language workflows.
You describe the journey in plain English, something like "go to the contact page, fill out the form and submit it". DevAlly Agent walks through your site the way a user would. It handles things like cookie banners, asks you for sign-in details if it needs them, and records the journey. You review the steps, watch a replay of what it did and confirm it's right, because you know your product better than any AI does. There's a human in the loop all the way.
From then on, DevAlly audits that journey. It brings back every issue with the WCAG success criterion it fails and a recommended fix, which you can push straight to your editor through the DevAlly MCP. Every time you ship, the journey can be checked again. A release that breaks checkout for keyboard users gets caught before your customers find it.
And yes, the DevAlly Agent chat works with a screen reader. It would be a bit awkward otherwise.
It's in beta and open to every DevAlly user, including our Free plan. There's no waiting list.
Which journey would you check first? @darrenbritton(CTO) and @bruno_walraven(Head of Product) are here all day for the hard questions.
@darrenbritton @bruno_walraven @cormacchisholm Most teams test the homepage and a few templates, then hope checkout is fine. A checkout that's 90% accessible still blocks people, so testing whole journeys makes a lot of sense. Good that a person reviews the steps too
Exactly our thinking @oliver_graf1 ! Agentic workflows are going to change the current systems massively, but real people's experiences and the 'human' review is crucial to ensure the human user is understood
Hi DevAlly team! I did a lot of work on accessibility & section 508 ages ago. I'm assuming your targeted audience is for those who want to verify a website against WCAG. If so, what does the flow look like when the agent encounters an issue? the only images of DevAlly that I've seen are the ones included here.
also is it possible for the person using your product for testing to update the system prompt or give customized instructions to the agent? I noticed in my own AI engineering usage, I have to explicitly state my intention, e.g. "test this new way of deploying a feature" versus "get this feature deployed no matter what it takes." I'm wondering if you've noticed the agent brute-force a solution that should have otherwise been reported as a WCAG bug?
Congrats on the launch today!
@sara_ford_goog Thanks Sara, and great questions!
On the audience, one nuance: WCAG is the standard we test against, but what our users are usually trying to show is compliance with whichever regulation applies to them (EAA, ADA, Section 508 and so on), and we test whole journeys rather than single pages. You describe a real user journey in plain language, the agent walks it in a real browser, you review the recorded steps and a replay, and once confirmed it's a Workflow that is used to continuously monitor for accessibility issues.
When a Workflow run finds an issue, it simply reports it. Each finding comes with the success criterion it fails, the element, a screenshot and a suggested fix (which can go straight into your editor via our MCP), and we track every occurrence across runs so you can see what's new, regressed, or resolved.
On instructions: there's no separate system prompt to edit, because the journey description is the instruction. You tell the agent what to do in plain language, as prescriptively as you like:” go to the pricing page, open the Pro plan, add it to the basket, check out as a guest". The agent follows those steps, asking you for things like credentials when it needs them. So it's much closer to your "test this" framing than "get it done no matter what," since you're describing the path, not just the goal.
On brute-forcing, you've named the real risk: an agent could route around an inaccessible button by jumping straight to the next URL, and that bug would never get reported. Our guard is that the agent only records the journey, it never judges it, and you as the domain expert verify every recorded Workflow before it's saved, so a detour gets caught at review rather than baked into the test. Human audits on the platform then start from those same Workflows, so an auditor sees the exact path being tested too.
We would love to connect to hear more about your accessibility experience.
@bruno_walraven Hey Bruno, it sounds like you're aware of the brute-force workaround and have ways to mitigate it. I haven't worked on accessibility in a long, long, LONG time, like before Halo and Xbox came out, long time ago 👵 Good luck with the launch!
Congrats on the launch team! Does it replace a human audit? Or how does the agent work with a user?
@charlotte_mattu1 Thanks Charlotte! Short answer, no, it doesn't replace a human audit (and we'd be wary of any tool that claims to). Our Workflows are best thought of as a scoping and automation pass. You, as the domain expert on your product, create workflows with the agent that represent a real user journeys in your product. We scan those workflows for accessibility issues, and they also become the basis for any future human audits run through the platform.
Automation catches a lot, but questions like whether alt text is actually meaningful or whether a flow makes sense with a screen reader still need a person. So the agent handles the repeatable checks on every run deterministically, and when an auditor picks it up they start from your real user journeys with the automated findings already in place, rather than from scratch.
@cormacchisholm @darrenbritton Testing the whole journey is where the nasty accessibility issues usually hide. Really like this approach.
Thanks @harshyadav . We totally agree. So many testing platforms forget that users jump through multiple hoops, and don't always navigate in a linear format. This is why the agent helps find those issues, and suggest the fix too!
I like that people can review the recorded journey before the checks run. It gives them a chance to catch a wrong turn before it becomes a test they rely on. Congrats on the launch!
Thanks for your comment@oleksii_sekundant . When building the product, we realised that so many tools were building on mistakes, and without immediate remediation, the bugs multiplied. This way, you can catch, review and fix as you build.
Great idea and congrats on the launch! Accessibility audits and corrections take up quite a bit of time, so I appreciate something that does at least part of the work.
@mad94 Anything to help make accessibility easier for folks. Would love our feedback on the product, if you're up for it?
the journeys-not-just-pages framing is the right fix for the problem you describe, but I'm stuck on how the agent itself gets through the journey. if it's navigating via the DOM or a vision model clicking around, it can still verify each step passes WCAG rules, but that's different from the journey actually being completable by someone tabbing through with a screen reader, where the failure is often about focus order and timing, not any single element being non-conformant. does the agent walk the journey the way a sighted mouse user would, or does it attempt it the way assistive tech would, keyboard only, reading the announced state at each step
@galdayan hanks Gal! Today the agent navigates the way a sighted user would, with clicks and typing. It doesn't tab through the journey or read what a screen reader would announce at each step.
And that is intentional. The role of the DevAlly Agent is to work out how to accomplish a task in your application, capture the actions along the way, and turn them into a deterministic set of steps we can run again and again. That gives us two things: an automated audit of every state in the journey, and continuous monitoring so you know when something new issues appears, regresses or are resolved.
But automation can only fully evaluate around a third of WCAG's success criteria, and the agent doesn't change that. The ones you listed, focus order, where focus lands after an action, timing, whether what's announced makes sense, need a human audit. That's where the journeys earn their keep a second time: an accessibility auditor take the same journeys the agent captured and test them with a screen reader and keyboard navigation, with the automated findings already in hand. So the process is agent captures the journeys, automation catches what it can, and a human does the full manual audit on top of that.
@bruno_walraven that division makes sense, automation for regression coverage, a human for the parts that are actually about sequence and timing. one thing I'm curious about though: if the agent captures the journey mouse-first, does the auditor test that exact same path keyboard-only, or do they sometimes end up walking a different route through the page since a keyboard user doesn't always reach a screen in the same order a mouse click does. feels like it'd be easy to end up with two audits of two slightly different journeys without noticing