If you’re building or maintaining a financial services app in the UK, “make it accessible” isn’t a design nicety you get to when the roadmap allows. It’s a legal exposure question, and WCAG 2.2 is where the exposure gets specific.
Here’s what’s actually required, what’s genuinely new in 2.2, and where the legal obligation sits.
The legal backdrop most teams underestimate
Two separate obligations converge on the same point:
- The Equality Act 2010 requires “reasonable adjustments” for disabled users accessing services — including digital ones. Financial services aren’t exempt.
- The FCA’s Consumer Duty (in force since 2023) requires firms to avoid causing foreseeable harm to customers, including those with characteristics of vulnerability. An inaccessible app that locks out a visually impaired or motor-impaired customer from managing their own money is a live example of exactly that harm.
Neither the Equality Act nor Consumer Duty names WCAG explicitly as the bar to clear. But WCAG is the standard courts and regulators point to when asked what “reasonable” or “foreseeable harm” means in a digital context. Meeting WCAG 2.2 AA isn’t a guarantee against a claim — but it’s the strongest evidence you took the obligation seriously, and its absence is the first thing a claimant’s solicitor will note.
This matters more for financial services than almost any other sector. The FCA’s own research shows disabled customers and those with characteristics of vulnerability are disproportionately represented among people who struggle with digital-only services — precisely the population Consumer Duty was written to protect. An accessibility gap in a banking or investment app isn’t a UX rough edge; it’s a documented category of harm the regulator has already named.
What’s new in WCAG 2.2
WCAG 2.2 (published October 2023) added nine new success criteria on top of 2.1. The ones that matter most for financial apps specifically:
2.4.11 Focus Not Obscured (Minimum) — a keyboard-focused element (a button, a field) can’t be completely hidden behind a sticky header, cookie banner, or chat widget. Fintech apps with persistent nav bars and support chat overlays are exactly where this bites.
2.5.7 Dragging Movements — any function that requires a drag gesture (reordering a watchlist, adjusting a slider for a loan amount) needs a non-drag alternative. Pure drag-only sliders for things like repayment amounts are a common failure point.
2.5.8 Target Size (Minimum) — interactive targets need to be at least 24×24 CSS pixels, unless equivalent spacing is provided. Dense financial dashboards with small icon-only buttons are a frequent offender here.
3.3.7 Redundant Entry — don’t make users re-enter information they already gave you in the same process. Multi-step KYC or onboarding flows that ask for the same detail twice (once in a form, again in a confirmation step) fail this.
3.3.8 Accessible Authentication (Minimum) — authentication can’t rely solely on a cognitive function test (remembering a password, solving a puzzle) unless there’s an alternative — think copy-paste-friendly password fields, or support for password managers, rather than blocking paste on login forms. This one directly conflicts with some legacy “security” decisions that disable paste on password fields.
The remaining four 2.2 criteria (Focus Appearance, Consistent Help, and two more granular authentication rules) matter too, but the five above are the ones that consistently surface in our audits of fintech and payment products specifically.
Where teams actually fail
In our testing work across fintech clients, the recurring failure points aren’t exotic — they’re the basics that get skipped under deadline pressure:
- Color contrast ratios below 4.5:1 on balance figures and status indicators — often because a brand palette was chosen for aesthetics before anyone checked contrast
- Form errors communicated by color alone (a red border with no text or icon) — invisible to colorblind users and screen readers alike
- Custom components (date pickers, dropdowns, toggle switches) built without proper ARIA roles, so screen readers announce nothing useful
- Session timeouts with no warning or extension option — a serious issue for users who need more time to complete a transaction
- Charts and graphs (spending breakdowns, portfolio performance) with no text alternative — the data exists only as a visual
None of these require a redesign. They require testing that specifically checks for them, rather than assuming a component library handles it out of the box. A component library gets you partway there; it doesn’t validate how your team has actually wired it into a real user flow.
What “meeting WCAG 2.2 AA” actually means in practice
AA is the conformance level referenced by UK public sector regulations and the level most legal guidance treats as the reasonable baseline for private sector digital services, including financial ones. It sits between A (minimum) and AAA (enhanced, rarely fully achievable across an entire product).
Meeting it means testing across four principles — perceivable, operable, understandable, robust — with a mix of automated scanning (catches roughly 30-40% of issues) and manual testing with actual assistive technology: screen readers (NVDA, JAWS, VoiceOver), keyboard-only navigation, and screen magnification.
Automated tools alone will tell you your alt text exists. They won’t tell you it’s useless (“image1.png”) or that your custom dropdown is invisible to a screen reader despite looking fine visually. This is the same gap we see in functional testing more broadly — automated coverage tells you something ran, not that it works for the person actually using it.
How this fits into a broader testing programme
Accessibility testing isn’t a one-off audit you run before a launch and forget. It belongs in the same regression cycle as your functional and security testing — new components and flows should be checked against WCAG criteria before they ship, not discovered after a customer complaint or a Consumer Duty review flags them.
Our accessibility testing work sits alongside broader user experience testing for exactly this reason: an inaccessible flow is a usability failure for one set of users and a compliance failure for the business, at the same time. Treating them as separate problems usually means neither gets properly resourced.
The practical starting point
If you haven’t done a WCAG 2.2 audit yet: start with an automated scan to catch the low-hanging fruit, then prioritise manual testing on your highest-traffic and highest-risk flows first — onboarding, payments, and account management, not your marketing pages. Those are the flows where a Consumer Duty complaint is most likely to originate, and where fixing issues has the most impact on real users.
Need an accessibility audit that goes beyond an automated scan? We test with real assistive technology against the flows that actually carry regulatory risk. Get in touch.