Banks risk mistaking AI-generated accessibility claims for proof, leaving defects to surface after deployment and potentially making essential services unavailable to customers, according to Preety Kumar, the founder and CEO of Deque Systems.
Deque research found that 88% of engineering leaders trust the accessibility of AI-generated code, even though 64% identify accessibility as a major cause of post-production rework.
Kumar told QA Financial that the apparent contradiction reflects growing pressure on development teams to release new digital services rapidly, combined with a misunderstanding of what AI coding tools can reliably validate.
“We’re seeing increasing performance expectations alongside a persistent and fundamental misunderstanding about AI’s abilities to perform accessibility testing,” she shared.
“Development teams are under immense pressure to ship new, innovative content and experiences. To achieve this, they are leveraging the latest AI agents to accelerate development.”
Although these tools can increase development velocity, Kumar warned that they also change how product, design, development and testing teams work.
“Too often, teams assume that prompting their agent to produce accessible output is sufficient and skip the vital step of verification.”
Prompting as ‘a starting instruction’
Nearly all respondents to Deque’s research said they prompt AI tools to generate accessible code. Kumar stressed, however, that an instruction given to an AI model cannot replace an enforceable testing process.
“Prompting is a starting instruction, not a control. It has no enforcement mechanism and no feedback loop. So, banks need validation built into the development pipeline itself.”
She said automated accessibility testing should be integrated into both the integrated development environment and the continuous integration and delivery pipeline, enabling defects to be caught before code is merged.
“You also need AI tooling that can pull from an expert-validated knowledge base that has been trained and validated against WCAG success criteria and ARIA patterns specifically, rather than general-purpose code generation.”
Human oversight must remain a mandatory part of the process, particularly when an AI-generated accessibility finding could be used as evidence of regulatory compliance.
“Finally, you need governance that requires uncertainty to be surfaced, not suppressed, when AI isn’t confident in its own assessment,” Kumar said.
“For a regulated industry like banking, that last point is particularly critical, an AI agent that quietly guesses at an accessibility judgment is a bigger liability than one that flags when it doesn’t know.”
Testing third-party banking services
The challenge extends beyond software developed directly by banks. Financial institutions increasingly depend on third-party components for payments, customer authentication and digital onboarding, but remain accountable for the resulting customer experience.
“This is one of the areas where accessibility debt hides best, because banks often assume a vendor’s compliance claims are current and accurate when they frequently aren’t,” Kumar said.
“Self-reported Accessibility Conformance Reports (ACRs) are facing increasing scrutiny, and several jurisdictions now require independent, third-party validation rather than accepting vendor self-assessment at face value.”
“Banks that continue to file accessibility under ‘compliance checkbox’ are going to be caught off guard.”
– Preety Kumar
Kumar said banks should manage accessibility in third-party systems as they would any other operational dependency, applying continuous monitoring instead of relying exclusively on checks performed during procurement.
“Instead of simply accepting a static ACR at signing, banks need to test vendor-embedded user flows and the components within them (a payment widget, an authentication screen, an onboarding form) directly in production, using real assistive technology, on a recurring cadence.”
Contracts should also require vendors to demonstrate their continuing testing and compliance practices, she added, because updates can introduce new accessibility defects into previously tested components.
Accessibility as service availability
Accessibility failures are often categorised as compliance or customer-experience issues. Kumar argued that banks should instead treat them as a component of digital operational resilience.
“When an accessibility defect prevents a customer from completing a payment, verifying their identity, or accessing their account, that’s not a cosmetic UX issue, it means there’s a service that has become unavailable to a sizable segment of your customers.”
“That’s functionally the same category of risk as an outage or a degraded system, and it deserves the same operational rigor.”
This distinction is becoming increasingly important as regulatory and legal expectations around accessibility develop.
“We’re seeing courts and regulators reject partial accessibility as insufficient, and they’re rejecting accessibility overlays as a valid substitute for genuine remediation,” Kumar said.
“Banks that continue to file accessibility under ‘compliance checkbox’ rather than ‘service availability’ are going to be caught off guard by both the regulatory environment and their customers.”
Shifting accessibility
Deque estimates that correcting an accessibility problem after deployment can cost 30 times more than addressing it during design. For large banks managing legacy technology and frequent releases, Kumar said automation is essential to moving accessibility testing earlier in the development lifecycle.
“The strategy has to start with automated testing built directly into the development pipeline, catching issues at the point code is written rather than after it’s shipped. That’s what makes shift-left possible at this scale.”
Automation can also allow banks to make more targeted use of specialist accessibility expertise.
“Rather than finding and fixing all issues manually, which is exhausting and time-consuming, engineers can review and validate issues surfaced by automation, while accessibility experts focus on the complex manual issues that automation isn’t yet capable of surfacing.”
Kumar pointed to one large organisation included in Deque’s research that used AI to apply fixes directly to its code, with engineers reviewing and approving the results.
“It cut a multi-week remediation effort down to a matter of hours. That’s a workable model for a large bank as well, test early, let automation absorb the volume, and have your teams apply human judgment and strategy where it’s genuinely needed.”
An auditable evidence trail
As AI coding agents become more autonomous, banks will also need to preserve evidence showing how accessibility issues were identified, remediated, reviewed and approved.
“As AI agents take on more of the remediation work, documentation becomes the compliance backbone,” Kumar said.
“Banks should retain records of what the AI agent was asked to assess, what it found, what it changed, and who reviewed and approved the change before it shipped.”
Under requirements such as the European Accessibility Act, Kumar said a defensible audit trail demonstrating human oversight could become as important as the technical correction itself.
“Banks should retain records of what the AI agent was asked to assess, what it found, what it changed.”
– Preety Kumar
Human testing remains necessary wherever AI and automated tools cannot adequately evaluate how customers experience a service, including its behaviour with assistive technology and its cognitive demands.
“Also, there is no substitute for the judgment of people with disabilities using the product day to day,” she stressed.
“AI can accelerate detection and even remediation at scale, but the final determination that something is genuinely accessible, not just automated-test-passing, has to sit with human experts.”
Kumar concluded that financial institutions now face a combination of growing regulatory enforcement and increasingly powerful AI-assisted development capabilities.
“The institutions that connect those two forces, that build accessibility into their AI-assisted development pipelines now, rather than bolting it on after an audit or a complaint, will spend less, move faster, and be far better positioned for a regulatory and customer environment that is only going to demand more,” she stated.
“The ones that don’t approach accessibility this way will find that the debt they’re accumulating today will only continue to build and come due at the worst possible moment. It’s a time of great risk, but also of great opportunity,” Kumar shared as a final remark.
NEXT MONTH
REGISTER TODAY – SIMPLY CLICK HERE
Why not become a QA Financial subscriber?
It’s entirely FREE
* Receive our weekly newsletter every Wednesday * Get priority invitations to our Forum events *
READ MORE
- Goldman puts AI coding to the test
- How to test AI models that banks do not control
- OpenAI, Filigran and SunTec: the latest vendor and product news
- Sygnum: Testing AI is ‘a measurement problem’
- Banks’ ‘code for all’ push raises testing risks
QA FINANCIAL PODCASTS
CLICK HERE TO LISTEN TO OUR EXCLUSIVE CONVERSATIONS
