We almost lost a deal because of color contrast. Not because our feature set was wrong, or pricing was off, or the demo went badly. The procurement team at a mid-sized European asset manager sent back a compliance checklist. Buried in section four was an accessibility clause, WCAG 2.1 AA conformance required across all user-facing interfaces. We didn't have documentation for that. We barely had a consistent focus state. I spent the next six weeks doing the most humbling work of my career. That was early 2022, but the lessons are still shaping how I build things now. I want to write about this properly because most accessibility content I find online is written for consumer apps, "make sure your button has enough contrast," and "add alt text to images." That advice isn't wrong, but it misses the specific complexity of financial interfaces. The stakes are different. The UI is different. In regulated markets, the legal framing is different, too. Why Finance Treats Accessibility Differently Consumer apps treat accessibility as a moral good, which it is. But in practice, it ends up on the roadmap between "dark mode" and "better onboarding", always almost prioritized, rarely actually done. Financial services don't have that luxury. In the UK and EU, financial institutions must comply with accessibility standards as part of broader digital inclusion and anti-discrimination frameworks. The European Accessibility Act will require compliance for most financial services by 2025. The UK's Equality Act 2010 already applies. WCAG 2.1 AA is the technical baseline that regulators and procurement teams reference when they actually check. When I first joined VALK in 2019, I thought of accessibility the way most product designers do, something to layer on after the core experience is built. After the procurement checklist incident, I understood that framing was wrong. Accessibility is a sales requirement in enterprise fintech. If your platform fails an institutional client's compliance audit, you don't get a second meeting. You lose the contract. Potentially millions in annual recurring revenue. The business case writes itself. The hard part is the implementation. The Data Visualization Problem Charts and data visualization are where financial interfaces get genuinely difficult from an accessibility standpoint. Our platform had portfolio performance charts, yield curves, asset allocation breakdowns, and common enough. The challenge is that a meaningful chart in finance often has eight to twelve data series. You're comparing multiple assets, multiple time periods, multiple metrics, and you need to differentiate them visually. The standard solution is color. Give each series a different color. But WCAG 2.1 requires sufficient contrast not just between text and background, but between any UI components that convey information. If you're relying purely on color to distinguish line A from line B on a dark background, you're failing users with color vision deficiencies, statistically about 8% of men. Here's what I discovered while testing: I am on the edge of that statistic myself. I ran a colorblindness simulation through one of our chart views and realized I genuinely couldn't distinguish two of the data series in our default palette. I'd been designing those charts for two years and never noticed because I'd always been looking at them with labels and legend context in view. Strip those away, and the colors blur together. The fix was not just changing the palette. We added pattern fills to area charts, made line charts use distinct dash patterns in addition to color, solid, dashed, dotted, and long-dash. Every data series got a unique combination of color, shape marker, and line style. It made the charts more complex to build, but actually more readable for everyone. For color specifically, I moved to a palette designed around perceptual distinctness rather than aesthetic preference. Colors that look great together on Dribbble are often terrible for colorblind users. I now test every palette in grayscale first; if the data series are indistinguishable in grayscale, color is doing too much work. Screen Readers and Financial Data Tables Our cap table management interface had tables with nested headers. Parent columns with child columns. Rows representing investors, sub-rows representing individual transactions under each investor. It looked clean and logical visually. Screen readers hated it. WCAG requires that data tables use proper semantic markup, scope attributes on headers, thead and tbody correctly structured, aria-label on tables where the heading isn't obvious. When a table has merged cells or multi-level headers, you need headers attributes that explicitly associate each data cell with the correct header cells. It is tedious. It is invisible work. And it's absolutely necessary for a screen reader user to understand that a number belongs to Q3 revenue for Investor B, not Q3 revenue in general. scope thead tbody aria-label headers I had to go through every table in the platform and audit the actual HTML output from our frontend components. Some of our tables were being generated from a grid library that didn't produce accessible markup by default. We had to either configure it differently or wrap the output with additional attributes. The honest reality: I couldn't test this alone. I don't use VoiceOver as my primary interface. I spent time reading, watching screen reader users navigate financial data on YouTube, and running tests with NVDA on Windows. You notice things quickly, how a screen reader announces "column header, column header, data cell" without context if the table structure is wrong, how it reads cells in an order that makes no sense if the DOM order doesn't match visual order. Getting this right took longer than any other part of the accessibility work. Keyboard Navigation in a Trading Interface Some of our institutional users, particularly at larger firms with strict IT environments, operate in contexts where mouse use is limited, or where power users prefer keyboard navigation for speed. And some users cannot use a mouse at all. Our deal approval workflow had a problem. Five-step modal flow: review deal terms, confirm investor details, upload signatures, and submit. Visually clean. Keyboard-only, a nightmare. Focus wasn't being set when the modal opened, so a keyboard user had to Tab through the entire page to reach the modal content. Tab order inside the modal was inconsistent because of how we'd structured the component layers in Figma and translated them to the DOM. Closing the modal didn't return focus to the element that triggered it. These are all WCAG 2.1 failures. The spec is specific: when a dialog opens, focus must move into it. When it closes, focus must return to the trigger. Interactive elements inside must be reachable by keyboard in a logical sequence. Focus management is one of those things that feels like a frontend problem, not a design problem. I disagree. If I hand over a modal design without specifying where focus goes when it opens, what the Tab order is inside, and what happens when it closes, I'm leaving that decision to a developer who may or may not think about it. Most won't. They'll focus on making it work visually. I started annotating focus flows directly in Figma. A simple overlay showing Tab order with numbered indicators, plus callouts for focus trap requirements. It added time to my handoffs but removed ambiguity. The dev team said it was the clearest accessibility documentation they'd received. Retrofitting is painful, designing with it from the start is less painful. By the time I did the accessibility audit, our component library had been accumulating debt for about two years. I had to open every component, buttons, inputs, dropdowns, modals, table cells, status badges, notification toasts, and check them against WCAG criteria. The status badge problem was particularly instructive. We used color to indicate deal status: green for approved, yellow for pending, red for rejected. Just a colored pill with a text label inside. I assumed the text label was sufficient. It wasn't. WCAG's guidance on color dependency says color cannot be the only visual means of conveying information. The text label helped, but users with low vision who increase font sizes might see the pill without context. Screen readers announce the text, not the color. The fix was to add an icon to every status badge: a checkmark for approved, a clock for pending, and an X for rejected. Now, color, icon, and text all communicate the same state independently. only This sounds minor. Multiplied across twenty different status types in a complex financial platform, it's significant design and development work. Doing it as a retrofit, touching every instance of every component and every place they appear, took far longer than it would have if I'd built it correctly from the beginning. That's the real lesson. Accessibility isn't expensive when you design for it. It's expensive when you ignore it until an audit forces you to go back. The plugins that helped and the ones that didn't. I used several Figma plugins during the audit and redesign process. Contrast and A11y - Color Contrast Checker are genuinely useful for checking text contrast ratios quickly. I used these constantly. They're not perfect; they check static frames, not interactive states, so you still have to manually check hover states, focus states, and disabled states. But for baseline checking, they save significant time. Color Blind by Stark is the plugin that changed how I work. It simulates eight types of color vision deficiency directly on your Figma frame. I now run this on every screen with a chart or color-coded data before finalizing. The simulation that caught the issue in our chart palette was worth the plugin alone. Able has a more comprehensive checklist approach. I found it useful for learning what to check, less useful as a daily workflow tool; the checklist becomes repetitive once you've internalized the requirements. What no plugin replaces: actually using a screen reader. Figma plugins check design files, not the live product. The real test is in the browser, with VoiceOver or NVDA, navigating the actual interface. Design tools can give you a head start, but compliance requires live testing. The Institutional Client Dynamic Something specific to enterprise fintech that doesn't get discussed enough: your actual users are not always the ones who decide whether to buy your product. A portfolio manager at an asset management firm uses our platform daily. But the decision to purchase was made by a procurement team that evaluated security documentation, data handling policies, regulatory compliance evidence, and accessibility conformance documentation. The procurement checklist asks whether you comply with WCAG 2.1 AA. There's a checkbox. It doesn't ask whether your users find it delightful or whether the onboarding is smooth. After the near-miss in early 2022, we commissioned a third-party accessibility audit and got a conformance report. This document, a dry, technical PDF listing which WCAG criteria we pass and which had been remediated, became a sales asset. It goes in the proposal alongside our security certifications. When a new institutional prospect asks about accessibility compliance, we have documentation. That's the reality of selling into banks and asset managers. Their IT and compliance departments have requirements. Meeting those requirements is not differentiating; it's qualifying. You need it just to be in the room. What I'd tell someone starting this work now. Understand the standard first, not the tools. WCAG 2.1 is publicly available and readable. The actual criterion text is denser than it should be, but there are good plain-language guides. Understand what AA requires; it's more specific than most designers realize, and less overwhelming than many fear. Design for redundancy. Status, state, and meaning should never be communicated by color alone. Add icons, labels, patterns, shapes. Redundancy in information design is not clutter; it's clarity. Annotate focus behavior in your handoffs. Specify where focus goes when a modal opens, what the Tab order is, what happens when interactive elements are added or removed from the DOM dynamically. Don't leave it implicit. Test in the live product, not just in Figma. Plugins help. The real interface is where compliance happens or fails. And if you're working in financial services, treat this as a business requirement. The moral argument matters, but in enterprise sales, it doesn't get procurement to check the box. The conformance report does. I'm still refining how we approach this at VALK. The DeFi interfaces we built for Merlin brought a different set of challenges, more dynamic data, more complex state, but the same underlying principles. Accessibility isn't a project you complete. It's a constraint you design within, from the start.

Figma

YouTube

What to Do When Your Design Work Stops Mattering: How to Adapt

Portfolio

Accessible Data Visualization in Fintech: Why It Matters

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

AI Products Have Terrible UX: Here's Why

Building an End-to-End Dynamic C# Web API with Dapper for Data Access

Data Integrity Is Vital for The COVID-19 Vaccine Rollout

Democratizing AI: How Difficult Can it Be?

The 3 Main Reasons Manufacturers and Distributors Should Use Data Integration Tools

Top 10 JavaScript Charting Libraries for Every Data Visualization Need

AI Products Have Terrible UX: Here's Why

Building an End-to-End Dynamic C# Web API with Dapper for Data Access

Data Integrity Is Vital for The COVID-19 Vaccine Rollout

Democratizing AI: How Difficult Can it Be?

The 3 Main Reasons Manufacturers and Distributors Should Use Data Integration Tools

Top 10 JavaScript Charting Libraries for Every Data Visualization Need

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps