The Accessible Default

Support That Enables

Engagement

All Sectors

Most retail financial services journeys are designed for a default user with full digital literacy, full sensory and cognitive function, and a stable life situation. Accessibility is bolted on at the margin — a separate phone line for visually impaired customers, a large-print pack on request, a screen-reader-compatible PDF posted out, an alternative form for people who cannot complete the digital flow. The customer who needs an adjustment must know to ask, find the route to ask, and accept a slower, narrower journey than the default offers everyone else. The asymmetry is structural and the Duty makes it indefensible.
The structural move is to invert the default: design every touchpoint to work for customers with the broadest realistic range of accessibility needs from the first wireframe, with WCAG 2.2 AA as the floor and FG21/1 as the framing. Bespoke accommodation becomes the exception, not the route.
Design to a stated accessibility baseline, not to the modal user
Every customer-facing touchpoint — web, app, document, form, video, voice, branch, ATM — must be designed to a published baseline. WCAG 2.2 AA is the floor for digital surfaces, with the relevant criteria embedded in the design system rather than left to a post-build audit: 1.4.3 contrast, 2.1.1 keyboard operability, 2.4.7 focus visible, 3.3.7 redundant entry, 1.3.5 input purpose, 2.4.11 focus not obscured. Reading-age, plain-English, and sensory-alternative standards apply to non-digital surfaces. The baseline is stated, owned, and tested against — not inferred from the FG21/1 obligation.
Test accessibility before architecture is committed
Conformance is set at design, not at release. Wireframes, prototypes, and journey maps are reviewed against the baseline before development begins; assistive-technology testing — screen reader, voice control, switch, magnification — happens iteratively with users who actually use those tools, not as a one-off audit. Third-party components are procured with WCAG conformance as a contractual requirement and tested in context, not in vendor demos. The design test: at what stage of the product lifecycle is accessibility evidenced, and would the firm be willing to ship a product that failed the equivalent test on security or fraud?
Govern the default journey, not just the accommodation route
Accessibility governance has historically lived alongside vulnerability and complaints — downstream functions that handle the cases the default journey fails. The pattern requires the governance to sit upstream: an accessibility owner in the design system, conformance reporting in product board MI, and remediation tracked against the same severity scale as functional defects. The Equality Act 2010 reasonable-adjustment route remains as a backstop for genuinely exceptional needs but is not the primary access mechanism. The design test: would a customer with a permanent accessibility need be able to complete the standard journey end-to-end without ever needing to invoke an adjustment?
- Every customer-facing surface — web, app, document, video, voice, branch, ATM — has a stated accessibility baseline (WCAG 2.2 AA for digital, equivalents for other channels), an owner, and reporting on conformance against that baseline that reaches product board MI alongside functional defect rates
- Assistive-technology user testing happens iteratively at design and prototype stage with users who use those tools daily, not as a one-off audit before release; third-party components carry WCAG conformance as a contractual requirement and are tested in context
- Customers with permanent accessibility needs complete the standard journey end-to-end at completion rates approaching the modal cohort; the reasonable-adjustment route under the Equality Act 2010 is invoked only for genuinely exceptional needs, not as the primary access mechanism for disabled customers
- Accessibility defects are tracked against the same severity scale as functional and security defects, with remediation timelines and product-board accountability; non-conforming third-party components are not procured without a remediation plan and a stated sunset date
- A retail bank reviewing its digital onboarding journey against WCAG 2.2 AA found that the accessible route differed materially from the standard route at the identity-verification step. The standard journey used a third-party video selfie tool that failed keyboard navigation, lacked screen-reader labels on the action buttons, and offered no captioned guidance. The accommodation route was a paper-based identity check that took up to fourteen working days and excluded the customer from instant account opening, debit card issuance, and the Current Account Switch Service window. Engineering classified the gap as a procurement issue: the vendor was selected on conversion metrics with no conformance clause in the contract. The bank rebuilt the step around a vendor selected under a procurement standard that required WCAG 2.2 AA evidence, ran assistive-technology user testing as part of the integration, and deprecated the paper route. Onboarding completion for screen-reader users moved from materially lower than the modal cohort to within a few percentage points, and the accommodation queue ceased to be the primary access mechanism for disabled customers. The FCA's digital design review framing — that the inclusive default is the design test, not the alternative channel — was directly cited in the post-implementation board paper.
- A life insurer audited its claims-form estate under FG21/1 and found that the bereavement claim PDF — the document a recently bereaved customer was asked to complete — was not screen-reader navigable, had reading-age in the high teens, demanded redundant entry of the deceased's details across three sections, and required printing and posting of a wet-signature page. The accommodation route was a phone call to a specialist team, but call-back times during peak periods exceeded the firm's own service standards. The insurer redesigned the form as a structured, accessible web journey with screen-reader-tested labels, save-and-resume across sessions, plain-English copy reviewed at reading age 12, single-entry of the deceased's details propagated through the form, and a digital signature route with a postal alternative for customers who preferred paper. Time-to-first-payment on bereavement claims fell, complaints citing form difficulty fell sharply, and the FCA's bereavement claim review was used internally as the comparator standard. The insurer also added accessibility conformance to the design-system check that every new form must pass before release.
Common failure modes
The most common failure is treating WCAG conformance as the end state rather than the floor. AA is a technical baseline; the Duty asks whether the journey actually works for the customer at the edges, which is a usability question that an automated audit cannot answer. A second is testing accessibility at the wrong point — running a conformance scan on a finished product, finding fixable defects, and shipping anyway because the release is committed. By that stage the architectural decisions that determine whether the journey is accessible have already been made. A third is conflating accessibility with vulnerability. They overlap, but a permanently blind customer using a screen reader is not vulnerable; they are using the journey as it should have been designed. Treating accessibility as a vulnerability flag risks routing competent disabled customers into a triage they did not need and did not ask for. A fourth is the third-party blind spot: identity verification, document viewers, video KYC, embedded calculators are frequently the least accessible parts of the journey, and procurement contracts often have no WCAG conformance clause. A fifth is mistaking an alternative channel for an accessible journey — telling a screen-reader user to call the contact centre is precisely the bolt-on response the pattern exists to remove.

Related Patterns

Evidence & Supporting Facts

FG21/1 (Guidance on the Fair Treatment of Vulnerable Customers) sets the framing that firms must design products, services, and communications to meet the needs of customers with characteristics of vulnerability — including disability — rather than relying on customers to disclose and request adjustments. Chapter 9 of FG22/5 reinforces that channel flexibility is a Duty obligation.

WCAG 2.2 conformance level AA is the practical UK benchmark for the Equality Act 2010's statutory duty on service providers to make reasonable adjustments for disabled customers. WCAG's POUR principles — perceivable, operable, understandable, robust — and criteria including 1.4.3 contrast, 2.1.1 keyboard, 2.4.7 focus visible, and 3.3.7 redundant entry are the operational anchors.

The FCA Consumer Support Outcome review (March 2025) found firms relying on accommodation routes for customers unable to use the default flow risked failing the Consumer Support obligation under PRIN 2A.6, and cited as good practice firms that designed inclusive defaults rather than parallel adjustment pathways. The review warned against treating channel substitution as a substitute for accessible design.

The FCA's Digital Design in Customers' Online Journeys review highlighted accessibility, comprehension, and inclusive design failures as a recurring source of differential outcomes between cohorts. Customers with accessibility needs who hit barriers tend to abandon rather than complain, so the harm is invisible to dashboards that read engagement and conversion as proxies for service quality.

AI Automation Lens

AI is reshaping accessibility on both sides. As a tool, it lowers the cost of conformance: automated audit tools can flag a substantial share of WCAG defects across large estates that would otherwise be untestable; image alt-text generation, captioning, and document remediation can be largely automated; conversational interfaces give some users a more accessible route into complex journeys than form-based design ever offered. Generative AI used to draft customer-facing copy can be tuned to plain-English reading-age targets and tested against screen-reader rendering as part of the production pipeline. As a risk, AI-driven personalisation can entrench inaccessibility — interfaces that adapt to inferred user preference, dark patterns optimised by reinforcement learning, voice interfaces that fail on non-standard speech, and biometric authentication that fails for users whose face, voice, or fingerprint does not match the training distribution. AI-generated synthetic content (diagrams, charts, explainer video) can be inaccessible by default if the production pipeline does not enforce alt-text, captions, and structural markup. The design test is whether the AI investment raises the floor of the default journey for the broadest range of users — or whether it raises it only for the modal user while pushing the long tail further into accommodation. The FCA's digital design review is explicit that personalisation must not become a vector for differential outcomes.