By Prasanna Krishna Sanagala, Ronak Shah, Sandeep Tailor, and Mani Manjari Velnati.
In our Engineering Energizers Q&A series, we highlight the engineering minds driving innovation across Salesforce. Today, we spotlight Prasanna Krishna Sanagala, Lead Software Engineer on the Agentforce Conversation Client (ACC) team. Prasanna helps build and scale the conversational UI platform powering experiences across Agentforce, Data 360, Content Builder, and other Salesforce products, supporting more than 2.1 million monthly actions across the platform.
Explore how Prasanna’s team tackled the challenge of managing hundreds of accessibility issues generated across distributed Salesforce cloud audits under strict M1 delivery constraints, and how the team engineered an MCP-based accessibility remediation workflow capable of translating WCAG requirements into scalable, framework-aware automated code remediation across ACC conversation surfaces.
What is the Agentforce Conversation Client (ACC) team’s mission in building an accessible conversational UI platform across Salesforce?
ACC is a conversational AI UI platform powering agent interactions across Salesforce products including Agentforce, Data 360, and Content Builder. Because ACC operates as a shared platform consumed across multiple clouds, accessibility issues introduced at the platform layer can propagate across every downstream implementation built on top of it.
Our mission is to build a scalable and accessible conversational platform where accessibility is treated as a foundational architectural requirement rather than a downstream compliance exercise. WCAG standards, semantic HTML, ARIA best practices, and accessible interaction patterns are embedded directly into the ACC component architecture and not added after the fact.
At the scale ACC operates, there’s no room for post-release validation. When the platform itself becomes the accessibility foundation for dependent customer experiences, getting it right at the source is the only viable approach.
When accessibility audits across Salesforce clouds generated hundreds of issues simultaneously, what operational constraints made accessibility remediation difficult at ACC scale?
Because ACC is consumed across multiple Salesforce clouds, teams run accessibility audits independently on their own release schedules. That created a real operational challenge where multiple audit waves could generate hundreds of remediation findings simultaneously, all landing in the ACC backlog at once.
Every issue required investigation, prioritization, remediation planning, and validation, all while the team continued shipping roadmap features under M1 delivery expectations. Accessibility work was competing directly with active platform development.
Initially, the team distributed accessibility ownership across engineers, grouped similar issues together, and coordinated directly with accessibility experts to accelerate remediation cycles and align on convergence strategy between ADK and ACC-specific remediation tooling. Over time, recurring patterns started emerging across components and workflows and it became clear that purely manual remediation wasn’t going to scale. Traditional engineering processes simply weren’t designed to absorb continuous accessibility audit spikes at this volume while maintaining platform velocity.
What limitations in traditional accessibility remediation workflows made resolving WCAG accessibility issues at ACC scale unsustainable?
Traditional accessibility remediation workflows rely heavily on manual interpretation and disconnected tooling. Developers run accessibility scans, interpret axe-core output, map violations to WCAG guidelines, determine remediation strategies, apply fixes, and manually validate results. At ACC scale, that workflow became unsustainable.
Accessibility violations are rarely simple fixes. Engineers must understand the violated WCAG requirements, affected DOM structures, impact severity, and the correct remediation pattern within the component framework, where repeating that process across hundreds of findings became extremely time-intensive. Manual remediation also introduced inconsistency, since developers carried different levels of accessibility expertise. Some fixes addressed symptoms instead of root violations, while others introduced regressions elsewhere in the UI hierarchy.
To reduce that overhead, the team began standardizing accessibility reasoning directly into the MCP workflow using structured remediation guidance, WCAG-aware rules, prioritized scoring, and consistent validation patterns. That was built on the foundation established by ADK a11y agent transforming remediation from fragmented manual debugging into a scalable, repeatable engineering process.
What limitations in existing accessibility tooling led the team to build an MCP-based accessibility remediation platform?
ADK a11y agent and AI tools provide robust scanning and violation detection capabilities across the platform. However, the core opportunity was that accessibility remediation remained fundamentally manual even when automated scanners were involved. While ADK and AI tools excelled at identifying violations, the ACC team’s opportunity was to complement those capabilities with a conversation UI-centric MCP-based remediation workflow focused on ACC domain.
That led to engineering an ACC-centric MCP-based accessibility remediation platform with a shared execution layer for accessibility analysis, automation, and AI-assisted remediation. Instead of every engineer independently interpreting raw findings, the MCP server injects deterministic accessibility context directly into the remediation pipeline using WCAG rules, axe-core analysis, structured scoring, and prioritized recommendations.
The result was a structured workflow: accessibility issue → ADK/ACC MCP scan → AI prioritization → AI-generated remediation → validation → pull request generation. That pipeline reduced roughly 80% of the accessibility remediation backlog while making remediation significantly more scalable across the ACC platform.
What engineering challenges emerged when translating accessibility requirements into framework-aware automated code remediation?
The biggest challenge was precision. WCAG guidelines are nuanced and highly dependent on implementation details where the correct remediation strategy for one component may be wrong for another depending on rendering behavior, interaction patterns, or component hierarchy. Generic accessibility fixes often fail when applied blindly across large UI systems.
To address this, the team embedded WCAG guidance directly into the MCP workflow so the remediation engine could reason against authoritative accessibility constraints alongside structured axe-core analysis, operating against deterministic rules and framework-aware remediation patterns rather than guesswork.
Lightning Web Components and ACC-specific architectural patterns introduced another layer of complexity. Many remediation tools assume generic HTML structures, so the team calibrated MCP outputs specifically around LWC rendering flows, state management patterns, and ACC component behavior to ensure generated fixes aligned with the existing platform architecture.
Validation was equally critical. The team introduced structured before-and-after comparison workflows to measure whether accessibility compliance scores actually improved after changes were applied. Engineers still reviewed generated remediations before merge to validate framework behavior, accessibility compliance, and platform stability.
As the team expands the MCP-based accessibility workflow beyond ACC, what challenges emerge in scaling AI-driven accessibility remediation across Salesforce?
The first major challenge is framework diversity. ACC is built primarily around Lightning Web Components focused on conversational surfaces, but other Salesforce teams operate across different architectures and engineering patterns and accessibility remediation rules that work well for ACC don’t automatically generalize across every organization.
The approach is designed to complement Salesforce’s existing ADK a11y infrastructure, which starts with scanning and violation detection as the foundation, then augmenting with Conversation Client framework-specific automated remediation built into the MCP workflow. Different teams can extend the MCP workflow around their own implementation needs as the shared accessibility scanning foundation.
Trust is equally critical. AI-generated remediation for something as nuanced as accessibility compliance requires developers to trust structured recommendations and AI-generated pull requests. Building that trust means delivering deterministic outputs, measurable validation, transparent scoring, and clear escalation paths for edge cases.
The long-term goal extends beyond fixing accessibility bugs faster. The vision is to build scalable AI-driven accessibility remediation infrastructure in partnership with our ADK/Accessibility Engineering org and be capable of operationalizing remediation across conversational AI surfaces throughout Salesforce.
Learn more
- Stay connected — join our Talent Community!
- Check out our Technology and Product teams to learn how you can get involved.
