accessiBe webinar: How to tackle accessibility debt with accessFlow

Welcome and Opening Poll

Sapir: Welcome, everyone. This is the first session in our summer series focused on AccessFlow. Today, we are tackling accessibility debt, an important and timely subject as we share several new product innovations and updates.

To get started, I am launching a quick poll about why you are here today. Is it because your accessibility backlog keeps getting deprioritized? Do issues only appear after launch, forcing you to scramble to fix them? Does no one on your team really own accessibility? Or are you managing multiple websites and finding it difficult to keep track? We will give everyone a few moments to respond.

Five, four, three, two, one. Let us look at the results. The majority of you said that no one on your team really owns accessibility. We also saw that accessibility work keeps getting deprioritized in the backlog. We will discuss each of these challenges and what changes when you have the right platform, workflows, and tools to address them.

Why Accessibility Debt Is Growing

Sapir: Accessibility is becoming a priority for many businesses, especially in the digital domain. The average number of accessibility errors per web page had declined over several years, but it increased by approximately 10% from 2025 to 2026. According to WebAIM research covering one million home pages, the average web page now contains 56 accessibility errors.

The percentage of accessible websites across the web has increased from roughly 3% to 4%, which is progress. At the same time, the number of errors continues to grow. There are several reasons for this, including the pace of change accelerated by AI, which we will discuss later.

We also conducted research with e-commerce businesses and found that 72% were confident in their accessibility efforts. However, when we asked whether they had validated those efforts, fewer than half had done so. There is still a gap between wanting to do the right thing, believing you are doing the right thing, and actually verifying it. That gap remains significant when approximately 95.9% of websites are not accessible.

With that, I will hand the conversation over to our speakers, Gil Toledo and Nick Engleton. I am excited for you to hear from them.

Speaker Introductions

Gil: Hi, everyone. It is great to be here to discuss AccessFlow and accessibility. I am Gil, the product manager for AccessFlow. I have been with accessiBe for the past three years and have worked exclusively on AccessFlow since its beginning.

Before moving into product management, I was a software developer for approximately ten years. I remember clearly what it felt like when work landed on my plate that was not directly related to the product I was building, whether it involved security, compliance, performance, or accessibility. Those tasks often lived outside my normal day-to-day workflow. They were harder to track, harder to prioritize, and disconnected from the tools and processes I used as a developer.

That experience strongly influenced how we built AccessFlow together with our own developers, who also need to manage accessibility. That is what we will discuss today. Nick, over to you.

Nick: Thanks, Gil, and thanks, Sapir. I am happy to speak with everyone today about AccessFlow. Like Gil, my background is in engineering, primarily back-end engineering but also front-end work. Accessibility was always difficult to prioritize when it competed with other work, and it did not naturally fit into the workflows we were using. That is one of the reasons AccessFlow was designed to make accessibility work easier. I am looking forward to showing you exactly how it can help.

Today’s Agenda

Gil: Today, we will discuss why accessibility so often becomes debt and gets left behind. Nick and I will show you AccessFlow at a glance, walk through several of its most important features, present a live demo, and leave time for questions at the end.

The Accessibility Workflow: Detect, Resolve, and Maintain

Gil: The first step in managing accessibility is detection. AccessFlow continuously scans websites and web applications against more than 150 WCAG rules rather than relying only on periodic audits. It monitors accessibility as code, content, and user experiences evolve. This means teams can identify issues when they are introduced, whether through a new feature release, content update, or design change. The goal is simple: make accessibility visibility automatic and proactive.

The next step is acting on the issues found. Finding issues is only part of the problem. The real challenge is fixing them efficiently. AccessFlow provides prioritized findings and code-level guidance to help developers understand the exact problem, what needs to change, and where to make the change. For repetitive or common issues, automation can assist with remediation. Built-in task tracking supports accountability and collaboration across developers, designers, project owners, and other teams. The overall objective is to reduce the time between discovering an issue and resolving it in production.

The final step is maintenance. Accessibility is not something you complete once and forget. It is an ongoing journey. Every release, content update, or deployment can introduce new issues. By integrating accessibility monitoring into CI/CD pipelines and existing development workflows, teams can catch regressions early and receive alerts when new issues appear. This shifts accessibility from a reactive compliance exercise into a sustainable engineering practice built into the development lifecycle and the team’s daily work.

The workflow creates a continuous loop: detect issues automatically, resolve them with actionable guidance, and maintain accessibility through ongoing monitoring as the product changes.

The Developer’s Dilemma

Gil: The developer’s dilemma is something I feel very close to. These are four patterns we repeatedly hear from development teams, including our own. They are not teams that do not care about accessibility. They are teams trying to build and release products quickly.

First, accessibility issues often surface after code ships. Second, accessibility competes with every other sprint task, with no structure protecting the work. Third, testing sits outside the build pipeline. Fourth, when issues are flagged, tools often explain what is wrong but do not explain how to fix it.

These problems have one thing in common. Teams are not necessarily saying that they have too many issues. They are saying they do not know which issues matter most, what the real problem is, or what should be treated as urgent. When everything is presented as equally important, nothing gets done.

The answer is a system that detects issues, assigns severity, prioritizes the most important work, and provides actionable fixes instead of simply creating a longer backlog.

Poll: What Is Holding Teams Back?

Sapir: We have another poll for everyone. What is holding your team back from making progress on accessibility? We will give you a moment to respond.

It is fun to watch the results come in live. Thank you to everyone who participated. Gil, what do you think about the results we are seeing?

Gil: They match what we experience. The first result I relate to most is that accessibility is hard to prioritize within a sprint. We feel that ourselves while developing the platform. Developers do not consistently address accessibility unless it is actually included in the sprint. We will discuss all of these challenges today.

Sapir: One result I found particularly interesting is that no one selected ‘accessibility requirements are unclear.’ I would love to hear more about that in the chat as we continue.

AccessFlow at a Glance

Gil: Let us continue with AccessFlow at a glance. These are only some of its features, but they are the features we believe help organizations advance toward accessibility most quickly and efficiently.

AccessFlow enables customers to manage accessibility across all of their websites and applications from a single platform. It begins with automated scanning on an agreed schedule, continuously reviewing digital assets and identifying accessibility issues. The platform surfaces both unique issues and issues that recur across multiple pages, helping teams understand the true scope of a problem and focus their work.

AccessFlow then prioritizes issues based on their impact on usability. We call that impact ‘severity.’ Severity levels are defined with our accessibility experts and informed by real human testing so that they reflect what truly affects users. Severity is central to effective prioritization.

From there, teams receive clear remediation guidance and can track progress through resolution. Because accessibility is an ongoing effort, AccessFlow continues monitoring over time to catch new issues and help ensure accessibility remains part of every release.

Nick will now explain our more technical developer tools, which bring accessibility into the software development lifecycle.

Developer Tools: SDK and MCP

Nick: We offer an SDK that enables teams to bring accessibility testing into a local development environment or run accessibility tests as part of a CI/CD pipeline. This is a powerful way to enforce accessibility and help ensure that code is accessible before it goes live.

We also offer an MCP, or Model Context Protocol. It brings issues identified on a website directly into an engineer’s coding environment, where they can work with that information alongside an AI assistant. Teams may also use the MCP within agentic workflows, where accessibility issues can potentially be addressed autonomously.

Sapir: I think this is your chance to shine, Nick. Let us move into the live demo.

Nick: Great. I will share my screen.

Live Demo: Dashboard and Multi-Domain Management

Nick: This is the main AccessFlow dashboard. As Gil explained, AccessFlow navigates a website on a regular schedule, which can be monthly, biweekly, or weekly. It visits the available web pages and audits the content for conformance with WCAG.

The platform identifies issues ranging from extreme severity down to low severity. Extreme and high issues often involve screen-reader compatibility or keyboard navigation. These are the highest priorities within WCAG and the most important issues for ensuring a site is usable. Medium and low issues still matter, but they more often involve best practices or optimal accessibility.

Based on the number of pages, the number of issues, and their severity, the platform generates an overall accessibility score. We typically recommend getting the score into the 85 to 90-plus range for stronger conformance, although higher is always better.

The dashboard tracks issues over time. If a company releases a new version and sees a sudden spike in accessibility issues, it can identify that change, add governance, or potentially roll back problematic code.

This view shows one domain, but AccessFlow also supports multi-domain management. In this example, my plan supports up to ten domains. I can add, deactivate, or delete domains as needed. The platform gives me a high-level overview of how each domain is performing, and I can open any domain for a detailed accessibility breakdown.

Exploring and Prioritizing Issues

Nick: The Explore page provides a granular breakdown of the issues raised for a particular site. From this screen, teams can order and filter issues in several ways.

AccessFlow identifies whether an issue is unique or recurring. A unique issue occurs once on the site. A recurring issue appears multiple times, potentially because of a reused component, a template, the header, or the footer. We want accessibility work to be as efficient as possible. By identifying extreme and high-severity issues that occur repeatedly, teams can prioritize a small number of fixes that may resolve many occurrences and move toward conformance more quickly.

When we open an issue, the platform provides a screenshot to help locate it on the page. It gives a WCAG-based description and a link to more information. It explains how to fix the issue in plain English, displays the rendered HTML, and provides a suggested fix.

In this example, the recommended fix changes a paragraph element into a navigation element and adds an ARIA label. We try to make suggested fixes as clear as possible. The platform also provides the selector, the web page where the issue was found, and a direct link to that page.

Collaboration, Verification, and Ticketing Integrations

Nick: Team members can collaborate on an issue inside AccessFlow by adding comments or assigning it to another user. Issues can also be exported to standard ticketing systems. This environment is connected to Jira, and AccessFlow also integrates with Asana, ClickUp, and other systems.

When an issue is exported into a ticketing system and marked as resolved there, that status is synchronized back into AccessFlow. Teams do not have to update the same issue in two places.

After marking an issue as resolved, the user can verify the fix. AccessFlow rescans the relevant page and checks whether the issue has actually been addressed. This real-time validation is particularly valuable for engineers who are still learning accessibility, because it confirms whether the change they made is a real fix.

Verification does not have to be triggered manually. Teams can also wait for the next scheduled scan, which will automatically verify the issue. An issue can be reopened later or dismissed if it belongs to content that is being retired and no longer needs remediation.

Rules, Pages, and Visualization

Nick: Beyond the general issue list, teams can view findings by rule. For example, they can find every missing alt-text issue and address those together. Issues can also be viewed by page. Because each organization knows which pages receive the most traffic, it can prioritize high-value pages such as the home page or checkout page.

A page can be re-audited as needed or opened in the visualizer to show exactly where issues appear on screen. In this example, green markers represent resolved issues and red markers represent live issues that still need attention. A user can select any marker, open the issue panel, and take action.

Auditing Critical User Journeys

Nick: Another important feature is Journeys. Journeys provides additional coverage for dynamic processes and critical customer flows. It is similar to an integration test, but it is simpler to configure.

A user records a journey through a browser extension by replicating the actions a real visitor would take. On an e-commerce site, that might involve selecting a product, adding it to the cart, opening the cart, and checking out. When the recording ends, AccessFlow captures every element the user interacted with.

During each scheduled audit, AccessFlow repeats those steps and audits any content that becomes visible during the journey. This is an effective way to test dynamic content that would not necessarily appear during a standard crawl. Whether a journey is essential depends on how the site is built, but it can provide critical additional coverage.

Auto-Resolve and AccessWidget

Nick: Auto-Resolve is another feature that helps teams move faster. It applies fixes to the rendered site from the user’s perspective without changing the site’s source code. The organization adds a small script to the site’s HTML. When the page loads, the script applies the selected fixes.

Not every issue is eligible for Auto-Resolve. Eligible issues are marked with a blue star. Teams can apply Auto-Resolve to all eligible issues or choose specific issues deliberately.

This can be an effective way to triage new accessibility issues. If a team adds new content and does not have the capacity to remediate every issue immediately, it can apply Auto-Resolve for temporary coverage. Later, it can disable Auto-Resolve and implement the fixes natively in the source code, which remains the recommended long-term approach.

A gray icon indicates that an issue is already being remediated by accessWidget. This particular site is audited by AccessFlow and also uses accessWidget. There is a useful synergy between the two products: accessWidget acts as a safety net and remediates what it can, while AccessFlow enables the team to identify anything not covered, prioritize it, and eventually make native source-code fixes.

MCP Demo: Fixing Issues in the IDE

Nick: The next part of the demo is the MCP. In my coding environment, you can see a conversation I had with an AI assistant using the AccessFlow MCP.

I asked the MCP to retrieve the most urgent accessibility issues in the codebase and organize them in a table. It returned five high-priority issues, including decorative-content, alt-text, and page-title issues.

I selected the alt-text issue and asked for its details and location in the code. The MCP returned the issue ID, severity, affected pages, and CSS selector, and it located the relevant code immediately.

I then asked it to apply the AccessFlow suggested fix. Because this was an alt-text issue, the fix only required adding one line: ‘Smartwatch with white band on white background.’ That description had been missing, which created a significant barrier for someone using a screen reader.

The line is now present in the source code, and I can push the change. I could also ask AccessFlow to mark the issue as resolved directly from the coding environment.

This was a straightforward fix that may not have required AI, but it illustrates how simple many accessibility improvements can be. Some teams are using the MCP in agentic workflows, where an agent calls the endpoint, retrieves urgent issues, makes fixes, and opens a pull request for review without requiring a developer to make every change manually.

We are also exploring a future feature called accessCode to support this type of agent workflow.

Why the MCP Accelerates Remediation

Nick: That is what I wanted to show in the core platform and the MCP. Gil, is there anything else you would like me to cover?

Gil: That was great, Nick. I will add one point. Developers generally did not sign up specifically to manage accessibility. They have products and features to build. The MCP may be the easiest and fastest way for them to solve accessibility issues.

One of our customers resolved more than 1,000 accessibility issues in a single month using the MCP, substantially more than customers that were not leveraging it. It is an extremely efficient feature.

Shift Accessibility Left

Gil: One of the biggest reasons accessibility programs struggle is that issues are discovered too late in the development lifecycle. Without AccessFlow, the process is usually reactive: teams build a feature, deploy it to production, and only then discover accessibility issues. Those issues are added to the backlog, compete with other priorities, and are often pushed from sprint to sprint.

With AccessFlow, accessibility shifts left and becomes part of the development process. As developers write code, the MCP can bring accessibility issues directly into the IDE, provide the information required to fix them, or pass the issue to an AI tool that can make the change.

This enables teams to fix code before it is committed. Automated checks in the CI/CD pipeline can then catch anything that was missed before it reaches production, allowing the team to decide whether to release the code or fix the issues first.

Instead of creating a separate stream of accessibility work, issues flow directly into the team’s existing development workflows and sprint planning. Accessibility is fixed before release rather than after release, reducing remediation costs, reducing noise, preventing technical debt, and helping ensure that every new product version, feature, and design change ships accessibly.

The core message is simple: instead of discovering accessibility issues after users encounter them, AccessFlow helps teams resolve them while the feature is still being built.

Onboarding and Ongoing Maintenance

Nick: Getting started with AccessFlow involves a relatively quick onboarding process. Each customer has a product support specialist who helps configure the first scan and audit the relevant content.

After the initial scan, the customer can review the results and prioritize the work using the approach we discussed: focus on extreme and high-severity issues, issues that occur on many pages, and issues on the highest-traffic pages. The team can use Auto-Resolve where appropriate and prioritize native fixes from there.

There may be an initial backlog, but within a few months most teams can reach a steadier state focused on maintaining accessibility. Integrating accessibility into CI/CD moves the work even earlier, so many issues are addressed before they ever appear in the AccessFlow platform. Any remaining issues can be resolved efficiently through the MCP.

Sapir: We recently completed a case study with a customer that tripled its accessibility score in under three months. That is a powerful example of what this workflow can achieve.

Key Takeaways

Gil: Before we wrap up, I want to leave you with several key takeaways.

First, accessibility debt is real. Most organizations are not starting from zero. Their products are already built, and accessibility may not have been the first priority when they were small startups. Many are managing years of accumulated issues across multiple websites and applications. The goal is not perfection overnight. It is creating a process that systematically reduces that debt and prevents it from returning.

Second, the fastest way to make progress is to prioritize by severity. Not every issue has the same impact on users. By focusing first on issues that most affect usability, teams can deliver meaningful improvements more quickly and avoid becoming overwhelmed by the size of the backlog. Some customers begin with tens of thousands of issues, so prioritization matters.

Third, the biggest challenge is not usually identifying issues. It is the gap between when code is written and when it reaches production. The later an issue is discovered, the more expensive and disruptive it becomes to fix.

Finally, when accessibility becomes part of the development workflow, it stops being a separate initiative. It becomes another quality gate and another engineering standard built into how teams design, build, test, and release software. That is the vision behind AccessFlow: helping organizations move from a reactive approach to a proactive, continuous accessibility practice.

Final Thoughts

Sapir: We are nearing the end of the webinar, so this is the last chance to submit questions in the Q&A. Nick or Gil, are there any final thoughts you would like to share?

Gil: I will add one final thought from my perspective as the product manager. Developers like to create processes and tools that help them work more efficiently. They may work harder initially to automate something so they can do less repetitive work later, even though the workload never truly disappears.

That is what we are trying to accomplish with AccessFlow. Accessibility can feel intimidating. Anyone who has opened the WCAG guidelines knows they are long, technical, and difficult to interpret. That complexity can create a barrier between the work that needs to be done and the work developers want to focus on.

AccessFlow reduces the noise and uncertainty, focuses teams on what matters most, and gives them tools that fit naturally into their existing workflows. The goal is to make accessibility as simple, integrated, and achievable as possible.

Sapir: That was fantastic. Thanks, Gil.

Audience Q&A

Sapir: We have a question about pricing. I have already passed the attendee’s information to our sales team. Pricing is tailored according to site size and the specific features that would provide the most value. Gil and Nick, is that an accurate explanation?

Gil: Correct.

Nick: Yes.

Sapir: Another question asks how AccessFlow can be used for mobile and TV applications. Is that something we already support, or is it still on the roadmap?

Gil: We do not currently support native mobile applications directly. However, AccessFlow can work with any web application. If a mobile application uses a web application underneath, AccessFlow can support that web layer. The same may be true for some TV applications, although I am less familiar with those implementations and cannot confirm support for every TV app.

Sapir: That is interesting and gives us something else to explore. If there are no additional questions, we will end here. We will follow up with the webinar recording and look forward to hearing your feedback. Have a great day, everyone. Thank you.

Gil: Thank you. Bye-bye.

Nick: Thank you.