Accessible Banking Application Design That Meets WCAG 2.2
Making Banking Usable for Customers Your Testing Never Included
Accessibility work in banks usually arrives as a remediation project after an audit, a complaint, or a legal letter. A consultancy produces a report with several hundred issues, teams fix the ones that are cheap, the report is filed, and the next release reintroduces half of them because nothing changed about how the software is built.
The alternative is not more remediation. It is treating accessibility as a property of the design system and the delivery pipeline, and measuring it the way you measure performance. An accessible banking application is achievable with the teams you have, and the standard to build against is now clear.
What does WCAG actually require?
Conformance at one of three levels against four principles, updated most recently in December 2024.
The Web Content Accessibility Guidelines 2.2 became a W3C Recommendation on 12 December 2024. It defines conformance levels A, AA, and AAA, rests on four principles, and adds nine new success criteria while remaining backward compatible, so a site conforming to WCAG 2.2 also conforms to WCAG 2.1.
| Principle | Meaning | Banking example |
|---|---|---|
| Perceivable | Information must be presentable in ways users can detect | Statement data available as text, not only in a chart image |
| Operable | Interface components must be usable | Every payment flow completable by keyboard |
| Understandable | Content and operation must be comprehensible | Error messages that say what to do, not just what failed |
| Robust | Content must work with assistive technologies | Custom components exposing correct roles and states |
Which conformance level should a bank target?
Level AA, with selected AAA criteria where they help materially.
AA is the level referenced by most regulation and by procurement requirements, and it is achievable without distorting design. Treat it as the floor rather than the ambition, add AAA criteria where the benefit is clear such as enhanced contrast, and be honest in any published conformance statement about what has actually been tested. An overstated claim is worse than a partial one, because it will be checked.
What is new in 2.2 that matters for banking?
Accessible authentication, redundant entry, consistent help, target size, dragging alternatives, and focus appearance.
The nine new criteria in 2.2 land squarely on banking patterns. Criteria 3.3.8 and 3.3.9 address accessible authentication, 3.3.7 addresses redundant entry, 3.2.6 requires consistent help mechanisms, 2.5.8 sets target size expectations, 2.5.7 requires alternatives to dragging movements, and 2.4.11 through 2.4.13 cover focus visibility, obstruction, and appearance. Read as a list of banking defects, that is login, forms, mobile controls, and keyboard navigation, which is most of the app.
Has your application been assessed against WCAG 2.2, or against 2.1 and assumed equivalent?
Why do banking applications fail accessibility specifically?
Because the patterns banks rely on for security and data density are the ones most likely to exclude.
| Pattern | Failure | Fix direction |
|---|---|---|
| One-time codes and short timeouts | Cognitive and memory load, timeout under assistive use | Paste allowed, longer windows, alternatives |
| Session timeouts with abrupt loss | Work lost for slower users | Warning, extension, state preservation |
| Charts and spending visualisations | Information available only visually | Data table alternative, text summary |
| PDF statements | Untagged documents unreadable by screen readers | Tagged output, machine-readable alternative |
| Complex data tables | Structure lost without proper markup | Headers, scope, captions |
| Custom controls | Roles and states invisible to assistive technology | Use platform components or expose semantics properly |
| Hover-only interactions | Unusable by keyboard and touch | Focus and click equivalents |
| Inline error handling | Errors announced poorly or not at all | Programmatic association, clear instructions |
| CAPTCHA | Excludes several groups at once | Risk-based alternatives, non-visual options |
Why is authentication the most common failure?
Because security patterns deliberately impose friction, and friction falls hardest on people who already have more of it.
A six-digit code that must be read from one app, remembered, and typed into another within sixty seconds, with paste disabled for security reasons, is close to a worked example of an inaccessible pattern. WCAG 2.2's accessible authentication criteria exist because of exactly this. The good news is that the modern fix improves security too: passkeys and platform biometrics remove the transcription step entirely, and NIST's guidance supports that direction while cautioning that biometrics are not secrets and should be used only as part of multi-factor authentication with a physical authenticator. Where codes remain, allow paste, extend the window, and never rely on a single sensory channel. The authentication design is covered in passkey authentication for financial applications, and the same accessibility logic applies to voice channels as discussed in voice AI infrastructure for contact centres.
How does this connect to conduct obligations?
Through foreseeable harm and consumer understanding, not only through accessibility law.
The FCA's Consumer Duty sets a Consumer Principle that firms must act to deliver good outcomes for retail customers, with cross-cutting rules requiring them to avoid causing foreseeable harm and to support customers in pursuing their financial objectives, across outcomes that include consumer understanding and consumer support. An interface a customer cannot operate fails those tests regardless of what accessibility statute applies in a given market. That framing is useful internally, because it moves accessibility from a specialist compliance topic into the same conversation as product quality and customer outcomes, where it gets funded.
How do you test properly?
With layered testing, because each layer catches different things and automation catches the least.
| Layer | Catches | Effort |
|---|---|---|
| Automated scanning | Contrast, missing labels, structural errors | Low, run in the pipeline |
| Manual keyboard testing | Focus traps, unreachable controls, order problems | Moderate, high value |
| Screen reader testing | Semantics, announcements, comprehension | Moderate, needs skill |
| Magnification and reflow | Layout breakage at high zoom | Low |
| Voice control testing | Control naming and operability | Low to moderate |
| Cognitive walkthrough | Complexity, jargon, memory demands | Moderate |
| Testing with disabled users | Everything the others miss | Highest value, needs recruitment |
Why do automated tools catch only part of it?
Because most barriers are about meaning and flow rather than markup.
A tool can tell you an image lacks alternative text and cannot tell you the alternative text is unhelpful. It can confirm a control has a label and cannot tell you the label is meaningless out of context. It can verify focus is visible and cannot tell you the focus order makes the payment flow incomprehensible. Run automation in continuous integration to prevent regressions cheaply, and treat its clean result as the starting point rather than the conclusion. Then recruit a standing panel of disabled users, paid properly, testing real journeys, because their findings consistently change designs in ways no audit report does.
Does anyone with a disability test your payment journey before it ships?
How do you build it into the design system?
By fixing accessibility once in shared components rather than repeatedly in screens.
The design system is where this work pays off, because a correctly built component carries its accessibility into every screen that uses it. Invest in accessible form controls with proper labelling and error association, focus management that behaves predictably in modals and drawers, contrast tokens that cannot produce a failing combination, target sizes that meet the 2.2 expectations by default, and patterns that never depend on hover alone. Then make using the system the path of least resistance, since teams that build bespoke controls under deadline pressure are how regressions arrive. Portal and interface modernisation is where this usually lands first, as covered in this guide to agent portal modernisation and this one on mobile-responsive customer portals.
How do you handle statements and documents?
With tagged accessible documents and a machine-readable alternative.
PDF statements are a recurring failure because they are generated by document composition systems that were never configured to produce tagged output, so a screen reader encounters an unstructured page. Fix the generation rather than remediating individual documents, and offer a structured alternative such as a data export or an accessible web view, which also serves customers who want to use their own tools. Historic documents present a scope decision: retrofitting years of archives is usually impractical, so publish what you will provide on request and staff that process.
How do you handle vendors and third-party components?
By writing requirements into procurement and testing claims yourself.
Much of a banking interface is not yours: chat widgets, document viewers, payment components, identity verification flows, and analytics overlays. Require a current conformance statement against WCAG 2.2 at the level you target, ask which criteria are not met and why, secure a contractual remediation commitment with timescales, and retain the right to test. Then test, because statements are frequently based on older versions, on a component in isolation rather than in context, or on an optimistic reading. A vendor component that traps keyboard focus makes your whole page unusable, and the customer will hold you responsible rather than the supplier. The dependency discipline is the same one in third-party and concentration risk.
How do you sustain it rather than remediate repeatedly?
By putting accessibility into the definition of done and the pipeline, with named ownership.
Add automated checks to continuous integration so regressions fail a build. Include keyboard and screen reader verification in the definition of done for customer-facing work. Give accessibility a named owner with authority rather than distributing it to everyone, which means nobody. Train designers on the patterns rather than only developers on the fixes, since most issues are designed in before they are coded. And report accessibility state alongside other quality measures to the same forum, because anything reported separately eventually stops being reported. Self-service journeys are the highest-traffic surface and the right place to start, as covered in this guide to self-service portal design.
Which metrics matter?
Journey conformance, open issues by severity and age, regression rate, assistive technology completion, and user panel outcomes.
Report conformance by customer journey rather than by page count, since a bank with ninety-five percent of pages conformant and a broken payment flow has a broken bank. Track open issues by severity with ageing, because ageing high-severity issues are the honest signal. Measure regression rate, meaning issues reintroduced after a fix, which tells you whether the design system and pipeline are working. Measure task completion by assistive technology users on key journeys, which is the outcome rather than the proxy. And report findings from your user panel per release, since those are the issues that would otherwise become complaints. Device and performance constraints interact with all of this, as covered in mobile banking app architecture, and account opening is the journey where exclusion is most costly, as discussed in digital account opening.
Accessibility is unusual among quality attributes in having a published, testable standard and a population who will tell you precisely where you failed if you ask them. The banks that get it right stopped commissioning audits and started building accessible components, testing with real users, and failing builds that regress.
Frequently Asked Questions
What does WCAG 2.2 require?
Conformance at level A, AA, or AAA against four principles: perceivable, operable, understandable, and robust. It became a W3C Recommendation in December 2024 and adds nine success criteria.
Which conformance level should a bank target?
Level AA is the practical standard referenced by most regulation and procurement, with selected AAA criteria where they materially help, such as enhanced contrast.
What is new in WCAG 2.2 that matters for banking?
Accessible authentication, redundant entry, consistent help, target size, dragging alternatives, and focus appearance criteria, which map directly onto login, forms, and mobile interfaces.
Why is authentication the most common failure?
Because one-time codes, short timeouts, and copying values between apps impose cognitive and memory demands that WCAG 2.2 specifically addresses with its accessible authentication criteria.
Is accessibility only a legal compliance matter?
No. Conduct expectations bite too, since the FCA's Consumer Duty requires firms to avoid foreseeable harm and support consumer understanding, and an unusable interface fails both.
Why are automated testing tools insufficient?
Because they detect a minority of issues, mostly technical ones. Keyboard operation, screen reader comprehension, and cognitive load require manual and assistive technology testing.
What is the highest-leverage investment?
The design system. Accessible components with correct semantics, focus management, and contrast fix issues once across every screen that uses them.
Is a vendor conformance statement sufficient evidence?
No. Statements are frequently optimistic or based on older versions, so test third-party components in your own context before accepting them.
