At Microsoft Build 2026, accessibility practitioners Aaron Gustafson, Jessie Lorenz, and Carie Fisher warned that AI tooling can amplify existing accessibility failures unless product teams embed inclusive practices early in the development lifecycle. Their talk, "Can Your AI Pass the Accessibility Test?", laid out a six-stage software pipeline where fixing issues later inflates costs by 10x, 100x, and 1000x as the product moves from planning to customer feedback.
Process over post-release patches
Gustafson, Lorenz, and Fisher argued that AI does not remove the need for accessibility work - it scales whatever process a team already uses. "AI does not fix a broken process; it accelerates whatever process you already have," the presenters said, according to the transcript. When design and planning stages ignore accessibility, AI-driven automation carries those same gaps into generated copy, layouts, and components, reaching more users and more surfaces.
The six-stage pipeline they described - planning, design, development and coding, code review and CI/CD, public release, and customer feedback - shows where accessibility work must land. Early-stage fixes are often a conversation and a low-cost adjustment. Late-stage remediation, in contrast, forces teams to rework shipped features at steep technical and legal expense. For teams applying AI for Product Development, the takeaway is that automation multiplies whatever process sits underneath it, clean or broken.
Why cost multiplies through the lifecycle
Jessie Lorenz pointed to a pattern the team sees repeatedly: accessibility issues become 10x more expensive to fix after development, 100x more after release, and 1000x more once they reach customer feedback. Generative AI and developer tooling can generate vast amounts of UI code and content in seconds, so a missing alt-text pattern or an inaccessible color contrast choice can spread across hundreds of screens before anyone notices.
The presenters stressed that integrating accessibility into design systems, CI/CD test suites, and code review gates keeps the cost curve flat. Without those guardrails, AI-based authoring tools simply reproduce the same assistive-technology failures at a larger scale, increasing customer-experience risk and remediation overhead.
What to watch in product development
Indicators that teams are embedding accessibility at the right level include automated accessibility tests running in CI/CD pipelines, design-token systems that enforce contrast and focus states, and AI-driven authoring tools that expose accessibility metadata. Designers and engineers building AI-powered interfaces can follow the AI Learning Path for UX/UI Designers to integrate accessibility constraints into design tokens and component libraries - a key step for scaling inclusion alongside automation.
Platform SDKs and vendor tooling that add first-class accessibility APIs for generated content will also signal that the industry is moving accessibility early in the lifecycle, rather than bolting it on after release.
Why this matters for product development teams
For product development teams, the Microsoft Build talk is a direct reminder that accessibility is an engineering lifecycle concern, not a post-release checklist. If your team relies on AI for copy, layout, or component generation, you need automated checks and accessible design tokens in place before you scale. Failing to do so means the same barriers will reach more users, and the cost to fix them will multiply long before a customer files a complaint.
Your membership also unlocks:
