From backlog to release: How developer and product teams simplify accessibility with AI

Welcome and Agenda

Josh: Welcome, everyone, to From Backlog to Release: How Dev and Product Teams Simplify Accessibility with AI. So happy to be here with you today. I’m Josh Basile, proud member of the accessiBe team. I’m a person with a disability who made it my life’s work to advance both physical and digital accessibility within all of our worlds. And today’s session is all about solving one of the biggest headaches developers face. How to move accessibility from a constant backlog item into a regular part of your release cycle.

Whether you’re new to accessibility, or looking to scale your program, we hope today gives you the tools, the inspiration, and clarity to take the next step. All right, so here’s what’s ahead. We’ll begin with a quick introduction of all speakers, followed by an overview of accessibility and the challenges developers often face. We’ll then introduce you to accessFlow, our developer-first platform that puts accessibility directly into your hands. We’ll guide you through a live demo, and preview a powerful new feature called MCP. And finally, we’re going to answer your questions live at the end.

So make sure to put any of your questions in the chat, or use the Q&A function at the bottom of Zoom. So let’s dive into it.

Speaker Introductions

Josh: All right, so, a little bit about me. So, after my freshman year of college, my life was flipped upside down during a family vacation at the beach. A wave picked me up and slammed me headfirst against the ocean floor, shattering my neck. That day, I heard a loud crack, and I ended up becoming paralyzed below my shoulders. I’m now a power wheelchair user. I went back to school shortly after, then finished undergrad, and then later graduated magna cum laude from law school. And for the past 12 years, I’ve been a practicing trial attorney.

During the pandemic, while I was stuck at home, I wanted to do more around internet accessibility. And that’s when I got connected with accessiBe. For the last four and a half years, I’ve served as the Community Relations Manager, helping to ensure that people with disabilities have a seat at the table to help build and advance our technologies going forward, and it’s been an incredible ride. And I’m now honored to hand it over to my colleagues, Gil and Jason. Gil, let’s start with you.

Gil: Thank you, Josh. Hi, everyone. I’m Gil, the product manager for accessFlow. I’ve been at accessiBe for almost three years. I’m also a former developer. I was a developer for around ten years before becoming a product manager. That background helps me understand development workflows and what developers do and do not want from their tools. It helps us build a better product for fixing accessibility issues.

Josh: Thank you, Gil. Gonna throw it over to Jason.

Jason: Hey guys, my name’s Jason. I’m a QA engineer here at accessiBe. I’ve worked here for about four and a half years. Before I worked here, I was a teacher for children with special needs. I did that for about six years, teaching grades three through eight. Working at a company focused on accessibility felt like a natural progression for me and gave me another way to contribute to advocacy.

Josh: Awesome. Yeah, both Gil and Jason are awesome team members, and we’re very, very lucky to have them, and I’m so excited for them to do the demo and talk so much more with all of you today.

Why Digital Accessibility Matters

Josh: Accessibility is about more than just compliance. It’s about people, at the end of the day. It’s about ensuring that everyone, regardless of ability, can access and engage with your digital content. As someone who uses assistive technology every day, I can tell you, when a website gets accessibility right, it changes everything. And when they don’t, it sucks. It’s a horrible feeling that I don’t want to put on anybody. But I use voice dictation, I use an on-screen keyboard, I use keyboard shortcuts, a mouth-controlled joystick, and a screen reader. Each of these tools is powerful for me.

And they bring me independence, but if your website isn’t accessible, I get stuck right at the home page. Drop-downs may not open. Search bars that don’t focus. I may not be able to complete credit card fields with my voice. I always compare web accessibility to someone’s home. In the physical world, if the bones of a home or website aren’t solid, it doesn’t matter how beautiful the design is; it won’t be functional for people like me. The goal of web accessibility isn’t just about compliance, it’s truly about reliability, usability, and better customer experiences.

Compliance and the Developer’s Dilemma

Josh: Compliance pressures are real. I know you and your companies feel that pressure every day. And WCAG is the global standard, and more countries, agencies, and courts are now enforcing it. As a trial attorney myself, I’m acutely aware that lawsuits are on the rise. Litigation gets messy, time-consuming, and costly. Yet for developers, these guidelines feel like more technical, disconnected, and overwhelming. That is why we build solutions at accessiBe that make it easier to meet these standards without requiring every developer to be an accessibility expert. Doing it right from the beginning saves your teams time and reduces rework, risk, and reputational damage.

Now let’s look at where accessibility tends to get stuck. So, the developer’s dilemma. I know this slide probably looks very familiar to all of you. You’ve got deadlines, sprints, legacy code, unclear requirements, and limited accessibility training. But with accessibility getting delayed, it’s not because you don’t care, it’s because you just either don’t know where to start, or it doesn’t feel doable at that time. So we get it, and that’s why we built accessFlow with this reality in mind. I’m going to hand it over to Gil and Jason to talk through this in more detail.

Prioritizing Accessibility in Development Workflows

Gil: As a product manager and former developer, one issue that stays top of mind is prioritization. Accessibility tasks can be hard to prioritize. Prioritizing accessibility tasks can be difficult. Even as an accessibility company, we still have core products, features, and deadlines competing for attention. When accessibility issues are tracked in a separate platform, it can be difficult to incorporate them into regular development workflows. This is one reason we built a feature that connects accessFlow to ticketing systems like Jira, ClickUp, and Asana. We can export issues, and the accessFlow team uses the platform internally to help ensure our own product is accessible.

This integration brings accessibility tasks directly into developers’ working sprints. That way, everything is being tracked, and progress is being noticed, and developers are not surprised by issues they did not plan for during the sprint. So that’s one thing that really, really helps us.

Josh: I truly don’t believe any business wakes up saying, ‘I want to exclude disabled customers.’ Too few businesses give developers the time and tools they need to make accessibility efficient. Now that you know there are options and understand what to do next, you have the ability to bring accessibility to your digital products and to your customers. So this is an incredible opportunity. One of the things I love most about accessibility is that we’ve truly created, a comprehensive platform for web accessibility tools and solutions, and you’re not alone on this journey.

With AI-powered automation, manual remediation, and expert guidance, we can help you manage accessibility from start to finish. And again, you don’t have to do it alone. Whether you’re building something new or fixing existing issues, we’ll meet you where you’re at and tailor the right solution for your needs. So with that, again, I want to hand it over to Gil, who will show you how accessFlow can help solve many of these challenges.

Gil: Thanks, Josh.

Introducing accessFlow

Gil: So, what is accessFlow? accessFlow is your accessibility copilot. It handles the heavy lifting, automatically detecting accessibility issues, organizing them into actionable tasks, and guiding developers on how to fix them. There is no complicated setup required, and teams do not need to rely on outside experts for every issue. It’s just a faster and easier way for teams, for development teams, to make their sites accessible and keep them accessible. As I mentioned, it integrates seamlessly into teams’ existing workflows and tools, like GitHub, Jira, and others. How does it work at a high level?

Our AI-powered engine automatically scans your site, your SaaS platform, your web application, crawling pages, elements, and user flows to flag accessibility issues. Then it turns those findings into prioritized tasks with clear code examples and explanations, and real-time tracking. So, fixes fit naturally into development teams’ workflows. Continuous monitoring alerts you to new and resolved issues, keeping accessibility embedded in your day-to-day processes. It is always better to show this in real time, so let’s jump into a live demo and see how it all comes together. I’ll share my screen.

Live Demo: Dashboard and Issue Management

Gil: So, this is the accessFlow dashboard, the central hub for understanding your accessibility posture at a glance. It shows you your latest scan results, compares them with the previous one, and tracks your progress over time. You can view your accessibility score, the number of issues and pages found over time, and severity trends so you can track your progress and see issues decrease. We also highlight the potential impact of fixing issues. So, for example. If you choose to fix all issues categorized as extreme severity, you could increase the score from 78 to 94. Moving to our Explore page.

The Explore page is where you can view all the issues across your website in several ways. You can view a general list of issues across pages and user flows, or group issues by rule if you prefer to address accessibility one rule at a time. You can also organize issues by web page if you want to prioritize your main or highest-traffic pages. Now. Developers can see on each issue the high-level details in order to choose what to work on, and once they click an issue. They see. they will see our remediate. they will see our remediation panel. Did remediation.

Panel shows the developer what’s the issue, how to generally fix this issue, and it even gives the developer the code from the actual site, and we also show him how the code should look to become accessible. Developers can copy and paste the suggested fix directly into their development environment. We also show the affected element and the page where it was found.

Auditing Critical User Journeys

Gil: Another very important feature is Journeys, which we are very proud of. The Journeys feature enables users to record and audit critical user journeys using our Chrome extension. This can include form submissions, checkout processes, hotel bookings, and other journeys tied directly to website KPIs. Issues found within a recorded journey are separated from the general issue list, allowing developers to focus on and remediate that specific flow. Let’s see how it works. So, first of all, I can choose where to start from.

In this demo, I’ll start on the home page, but an e-commerce team could begin from the cart page or any other relevant point in the journey. Let’s see how it works. Before recording begins, the tool opens the site, creates a fresh user session, and performs any necessary pre-audit steps, such as bypassing a login wall. If you’re a platform, you probably have a login wall. Or if you have any blocking pop-ups that are not related to that. In my demo site, the most critical journey is booking an appointment. You can see the recorder loaded through the Chrome extension.

Once I click ‘Book an appointment,’ I can begin reproducing the user journey. We input the details, for example. You can even pick a date. And then, I click the book button. All those steps were recorded. Every element and interaction is recorded. When I click ‘End Recording,’ the journey returns to accessFlow so I can review and validate the steps before starting the audit. And this journey, of course, will be audited on any scheduled scan as a part of the regular site scan. This is included in addition to the regular site scan.

I also prepared an audited journey in advance to save time. You can see that this journey contains only the issues encountered during the steps I recorded. So, everything is scoped under this section, and it allows you to make sure that your most critical user journeys are remediated and accessible for everyone. Another very useful feature is Auto-Resolve.

Auto-Resolve

Gil: Auto-Resolve helps teams progress faster through their accessibility work. This feature has been developed to help you progress faster with your accessibility journey, because we know websites can have thousands of accessibility issues, making full remediation very time-consuming, and sometimes it could be a very long journey. That’s why we built this feature. By adding a simple script to your site, you can instantly apply user session automatic fixes, and focus your team on issues that require manual intervention. So, I can view all the issues that I can automatically resolve. The Explore page filters the issue list to show only issues eligible for Auto-Resolve.

So, let’s look at this issue, for example. This issue tells me that inline SVGs should be hidden from assistive technologies. And. As you’ve seen before, this is the source code, and this is the fix that the developer should apply. Let’s look at the issue on the live site. This is the actual element that we identified in accessFlow, and as you can see, there is no role presentation attribute, as accessFlow suggested to add. Once I click Apply Auto-Resolve, and I can see that the fix has been applied successfully. I can go into the website.

Within a few seconds, the fix is served to the website. I refresh the page. And you can see, it’s the same element, the role presentation attribute has been added, and the issue is now resolved. It won’t appear on any of the other scans, and it will remain auto-resolved until you choose differently. In the future, once the team has completed the native fixes that require manual intervention, it can remove the temporary Auto-Resolve fixes with a click. This keeps the team in control of which fixes are applied, when they are applied, and when they are removed.

To make the process even smoother, we created tools for developers’ AI agents that let them apply fixes where they write code, within their own environments and workflows. And Jason will now demonstrate how it works.

Jason: Thanks, Gil.

MCP Demo: Fixing Issues in the IDE

Jason: Hey everyone, again. So, I’m gonna share my screen now. Second.. As Gil showed, this is the Explore page. Here you can view all the issues on the website. In terms of the developer’s dilemma, fixes can be difficult when there are many issues to review. We created a tool that helps expedite those fixes directly within your IDE. So, for example, Here is the list of issues. I have already filtered them to show issues that occur multiple times across the website and have extreme severity. MCP lets you retrieve these issues within your IDE and remediate them directly in the codebase.

For example, I’ll ask MCP to retrieve the most urgent issues. The MCP is now processing the request. It is running the ‘get most urgent issues’ command and selecting the highest-severity accessibility issues on the website. The issues are ranked by severity. For example, the button roles issue occurs 264 times. So, it’s the same issue that’s here when we filtered and sorted this way. This example relates to an avatar icon. We can use MCP to retrieve the issue. We can then ask the agent to fetch the specific issue and apply the fix.

I will fetch the issue and ask the agent to apply the fix to the website. So, now it’s gonna give me all the details. It gives me the occurrences, the actual suggested fix. And it also asks, should I apply this fix to your codebase? Let’s apply it. So, as it’s thinking, it’s looking for the component. This is a React-based website, and the agent is locating the relevant component in the application. It identifies that the element has a pointer cursor but lacks the proper semantics, then adds the appropriate button role.

When we look at the code, we can see that the role has been added to the component. This is how we can bring accessibility directly into the IDE. The goal is to make accessibility work more seamless for developers by building it directly into their existing workflow. You can keep the fix and push the changes. That is a brief demonstration of the MCP feature.

Gil: Thanks, Jason. Yeah, that was, that was great, and I find myself, again, as a former developer. Seeing this in action is exciting because developers are always looking for ways to work faster and more efficiently, and when they don’t really know accessibility, bringing accessFlow’s accessibility knowledge directly into their development platforms. It is like giving those platforms accessibility superpowers, and it’s amazing to see it in action.

Josh: All about working smarter, not harder.

Gil: Exactly.

Jason: Indeed.

Audience Q&A

Josh: All right, now we are moving into the Q&A, so if anybody has questions, again, throw them into the chat, or the Q&A Zoom button at the bottom. I’ll start with a question for Jason. How quickly can teams get value from accessFlow?

Jason: The value of accessFlow is immediate. When a team adds its domain to the application, we run a scan of the website based on the selected number of pages. The team immediately receives a clear view of its accessibility status, including its score, the most severe issues, and guidance on what to fix and how to fix it. It provides actionable information that teams can use to begin their accessibility work immediately.

Josh: And Gil, how does accessFlow fit better into a developer’s workflow compared to other tools?

Gil: Yeah, so I said, we know most developers, aren’t accessibility experts, and it’s okay, no one expects them to be such. accessFlow is built to bridge the knowledge gap and empower developers to take ownership of the accessibility of their code. Developers also need to remain in full control of their code. So, accessFlow fits seamlessly into their existing workflows through the integrations and tools they already use, like Jira for task management. Or we have the accessFlow SDK that can run accessibility tests along your existing unit testing that you already have. It can fit in your CI/CD pipelines.

And combined with the MCP integration for the developer’s IDE, it becomes a natural part of the development lifecycle, helping them identify, prioritize, and resolve issues as early as they can, without leaving their own environment and tools.

Josh: Thank you, Gil. We got a good question from Gabrielle, so. Jason or Gil, if you want to answer it, but, What is MCP, and who has access to it?

Gil: I’ll briefly explain the idea behind MCP. MCP has emerged over the past year alongside the rise of AI agents. MCP connects data sources to an AI agent. As we saw in Jason’s demo, MCP works within the developer’s platform. Development environments such as VS Code or Cursor are where developers write the code for the site or application. MCP connects directly to those environments.

Josh: Thank you, Gil. And we got a question from Keith, Does this integrate into Drupal, and can this tool also work from front-end page creators when they are creating the pages?

Jason: Good question, Keith. Yes. As long as you can access the Drupal code in an IDE, you can use the tool for front-end development.

Josh: Perfect. We got one other question. Were you gonna say something, Gil?

Gil: Sorry, yeah, I just wanted to say that in general, accessFlow works with Drupal CMS, it scans it, and the only thing that you need is to have access to the code, like Jason mentioned, so there is no problem using it with Drupal.

Josh: Another question in the chat was, can the auto-resolve script be installed through Google Tag Manager, or would you recommend adding it directly into the codebase?

Gil: Yeah, it can be through Google Tag Manager, and I would actually recommend, if you already install other scripts through Google Tag Manager, you should also add the script the same way. So, it’s even recommended to add it through Google Tag Manager.

Josh: Great question. Jason, how is MCP different from regular Copilot suggestions?

Jason: MCP is different because it has dedicated accessibility context. Copilot uses general knowledge, but it does not have the same dedicated accessibility context, so. Our MCP draws on accessiBe’s accessibility engine, testing, and community-informed expertise, giving it a much stronger foundation for resolving accessibility issues.

Josh: Thank you, Jason. Now, we got a question from Adam. Can this tool be used on local environments, or is it only for sites on the web?

Gil: It can be used on local environments using our SDK. Local testing is an important step when releasing new code, and the SDK works within the local environment. And SDK reports can be viewed in the console as JSON or HTML, and it’s also presented in accessFlow UI. It also works in staging environments and on the public web.

Josh: Gabrielle also asked whether there is a trial for accessFlow or MCP.

Gil: There is a trial for accessFlow. MCP is not generally included, but if you contact us and mention today’s demo, I’ll make sure to open the MCP feature for you to trial.

Josh: Awesome. And right back at you, Gil, one more time. How do the SDK and accessFlow UI work together?

Gil: Yeah, that’s a great question, because there are different types of developers. Some developers prefer working in the console and focusing only on code, while others prefer the convenience of a UI. We support both approaches. So, developers can run the audits locally, for example, or in their CI/CD process. They immediately receive results in JSON or HTML, giving them all the issues and information they need. But all this information is also being uploaded to the accessFlow platform in a dedicated section for centralized tracking. In the UI, each SDK or test run appears in an audit table.

Opening an audit displays the full issue table with the same details available in regular scans, along with additional UI-based options. You can dismiss issues. You can comment on them if you want, The developer tools remain fully supported, while the platform provides centralized history and tracking.

Josh: Gil and Jason, thank you so much. We have one more question coming in. Give me one second. All right, so, can accessFlow provide a VPAT or ACR?

Gil: accessiBe can provide a VPAT. accessFlow is one of accessiBe’s products. For the ACR, I’m not sure; I would need to check.

Josh: I think that was the last question. Gil and Jason, thank you both for presenting today.

Closing Remarks

Josh: Before we wrap, I want to leave all of our attendees with this thought. Accessibility is not about perfection, it’s about progress. With accessFlow, you don’t need to be an expert, and you don’t need to start from scratch. You just need the right tools and the right team to support you every step of the way. Here at accessiBe, we got your back. So thank you so much for joining us today, and thank you for being a part of a movement toward a more inclusive world for all abilities. Thank you, everyone.

Gil: Thank you, Josh.

Jason: Thanks, Josh. Thanks, everyone.