Accessibility is
information equity.
In institutional finance, accessibility isn't a compliance checkbox — it's risk mitigation. If a person can't interpret critical data under pressure, that's a failure of the system, not the user. Here's how I design for it in high-density financial UX — and, just as importantly, an honest account of what I've measured versus what still needs real user testing.
conformance
pairs measured
audited surface
needs-testing
Density is where accessibility gets serious.
A marketing page is easy to make accessible. A trading grid with hundreds of live values, where a colour is the difference between buy and sell, is where the real work is. Three problems I design against.
High-density information
Visualising 960+ concurrent data points (as in the TradeX risk matrix) breaks naïve accessibility patterns. The design has to hold structure at scale.
- Reflow to 400% zoom without loss of function or horizontal scroll WCAG 1.4.10
- Semantic grid navigation — ARIA 1.2 Grid patterns so a screen reader moves row-by-row, column-by-column, keeping context inside a massive dataset
Keyboard-first workflows
Professional traders operate entirely by keyboard for speed. That serves mobility-impaired users and terminal power-users with the same design — a rare case where accessibility and performance point the same way.
- Focus management — logical tab order, visible focus, no focus traps in modal workflows WCAG 2.4.7
- Skip-to-action — hidden skip links and per-module bypass blocks for rapid access to execution panels WCAG 2.4.1
Colour-independent data
Markets run on red/green. But roughly 1 in 12 men has a colour-vision deficiency, and monochromacy exists. Direction can never live in colour alone WCAG 1.4.1.
- Redundant encoding — direction conveyed via ▲/▼ symbols + explicit +/− signs, not colour alone
- 3:1 Luminance contrast ratio — ensuring market data direction remains legible under total achromatopsia
Colour-Independent Data Demonstration
Icon (▲/▼) + explicit sign + 3:1 luminance contrast so market direction survives even total colour blindness.
What I've measured — and what I haven't.
A "WCAG AA" badge is easy to type and hard to earn. So instead of a badge, here's the register: what has actually been measured, and what still needs the kind of testing that a claim of "accessible" really requires. This mirrors my accessibility field note in full.
What the evidence supports
- 12 token contrast pairs measured against WCAG AA thresholds, spec-formula (not eyeballed)
- ARIA patterns documented — grid, dialog, live-region and disclosure patterns specified per component
- Keyboard paths walked — manual keyboard audit of focus order, visible focus, and bypass blocks
- Automated checks run — axe / WAVE passes, run by hand during design
What still needs doing
- No commissioned third-party audit. Self-assessment isn't the same as an independent one.
- No real screen-reader user testing. I smoke-test with NVDA myself — but testing with people who depend on screen readers is the evidence that actually counts, and I haven't run it.
- No automated a11y in CI. Checks run at design time, not on every commit, so regressions can slip.
- Coverage is partial. The measured work anchors a subset of components, not the whole system.
I'd rather show you exactly where the evidence ends than sell you a badge.
How I'd take it from documented to proven.
The honest gaps above aren't a shrug — they're a plan. Here's the replication path, with the order I'd run it and a rough sense of cost.
Wire a11y into CI
Add automated axe checks to the build so contrast and ARIA regressions fail the pipeline, not the audit. Days, not weeks — mostly configuration.
Screen-reader user testing
Recruit a small panel of people who use NVDA / JAWS / VoiceOver daily and run task-based sessions on the dense surfaces. This is the evidence the register is missing.
Commissioned audit
An independent WCAG 2.1 AA audit against the priority components, scoped to the surfaces that carry the most regulatory and financial weight first.
The evidence, up close.
Found a barrier? Tell me — I'd rather know.
Accessibility is a continuous practice, not a finished state. If you hit an information barrier on anything shown here, or have a suggestion, I want to hear it.