Alexandra BrooksChief Product Officer · Essays & perspective
← All essays

Accessibility5 min read

Accessibility on a shared banking app is decided by what clients may customise

Most accessibility failures in the shared app we run for credit unions came from features each credit union was allowed to change, not from the core code. A platform serving many institutions should restrict that customisation and measure accessibility by what disabled members can actually complete.

I used to think accessibility in a banking app was mainly an engineering discipline: label the buttons, check the contrast, test with a screen reader before release. That work remains necessary. My position now is that on a platform shared by many institutions, accessibility is decided earlier and higher up, in the agreement that says what each client may change. A shared platform that lets every credit union restyle the app will fail its disabled members however well the underlying code is written, and the platform's product leader has to be willing to say no to her own clients.

When I joined Lanternfield in April 2022, our 74 client credit unions each had their own version of the app. They chose colours, fonts, icon sets, the order of the menu, the words on its buttons and rotating promotional banners on the home screen. Credit unions value this. Many compete with banks many times their size and believe, with some justification, that a member who sees her credit union's own look feels that she belongs to it. Our sales team had sold configurability as a feature for a decade.

Where the failures actually came from

In mid-2022 we commissioned an accessibility review of the app as twelve credit unions had configured it, and we asked a panel of members who use assistive technology to attempt eight ordinary tasks: check a balance, move money between accounts, pay a bill, deposit a cheque, report a lost card, dispute a transaction, change an address and read a statement. Across the twelve configurations, members using screen readers completed 58% of the tasks without help.

The striking finding was where the failures sat. About seven in ten of the defects that blocked a task came from configured elements, not from the code our engineers had written. Brand colours failed contrast against white text. Custom icons had no text alternative. Promotional carousels moved on their own and captured a screen reader's focus. Menu labels had been renamed with internal jargon, so a member listening to the menu heard 'Member Hub' and had no idea it held her statements. Every credit union had made reasonable choices in isolation. Together they produced an app that a blind member could use at one credit union and not at the one across the river.

Fixing those defects one client at a time was not realistic. Each change needed the credit union's approval, configurations drifted with every release and each new marketing banner could undo the last audit. We would have been running an accessibility programme against our own clients' marketing calendars indefinitely.

One logo, one colour and a shared vocabulary

We proposed a single design system with sharply limited customisation. Each credit union could set its logo, choose one brand colour from a set we had tested for contrast in light and dark modes, and pick menu labels from a shared vocabulary written in plain language. Promotional content moved to a fixed panel that never moves on its own and cannot be published without a text alternative. Everything else, from type size to the order of the core tasks, became common to all 74.

The objections were serious. Several of our larger owner credit unions argued that we were turning their app into a generic utility and weakening their brand against banks with far larger marketing budgets. One chief executive told our board's product and risk committee that we were solving an accessibility problem by creating a commercial one. Hollin Prairie Credit Union, a client for nine years, left Lanternfield when its contract came up for renewal in 2024, taking about US$1.1 million of annual revenue with it, and its leaders were clear that the design restriction was the main reason.

I recommended the change knowing we might lose a client, and I told the committee so before it voted. I would make the same recommendation again. A member who relies on a screen reader did not choose her credit union for its accent colour, and she cannot easily move her mortgage, her car loan and her direct deposit because the app fails her.

Count completed tasks, not scanner warnings

The usual measure of accessibility is conformance: how many automated or audited failures against the Web Content Accessibility Guidelines remain. We still track that, and we treat version 2.1 at level AA as the floor. But a conformance report can look clean while members still fail, because the guidelines test components and members complete journeys. We now measure the eight tasks every quarter with a standing panel of 40 members who use screen readers, magnification, switch access or voice control, together with a group of older members and members with cognitive disabilities, who are often left out of accessibility testing altogether. In our most recent round, screen-reader users completed 91% of tasks without help, up from 58%. Magnification users reached 94%. Members with cognitive disabilities, the hardest group to design for, reached 83%, and that number tells us where next year's work lies.

The panel costs about US$380,000 a year, including payments to members for their time. It is the most useful research money we spend, because it finds problems no scanner can, such as a dispute flow that technically conforms but takes eleven minutes with a screen reader.

There are limits to this argument. A platform serving very different institutions may need more customisation than ours does, and one shared design will occasionally be wrong for a particular community. We built an exception process for that, approved jointly by product and our accessibility lead, and have granted it four times. I would not argue that branding is unimportant. I would argue that it belongs in the parts of an app that do not decide whether a member can reach her money.

My suggestion to any board overseeing a shared or white-label banking product is concrete. Ask management how many tasks a member using a screen reader can complete without help, at three different clients, and ask how many of the failures sit in what clients configure. If the second number is large, the remedy is a product decision about what clients may change, and it will cost something. It costs less than leaving the failures where they are.