Designing Accessibility as a System, Not a Checklist
How I led a cross‑product initiative to embed inclusive, EU-ready experiences into our fintech ecosystem, turning guidelines into everyday practice for teams and users alike.
Role
UX Lead
Platform
iOS & Android apps (Payzy, Payzy Pro), web portals
Timeline
2024 - 2025
Context & My Role
Our accessibility work covered the entire product ecosystem: the consumer payzy app, the payzy Pro merchant app, and supporting web portals, all of which started with minimal accessibility foundations and inconsistent support for assistive technologies. As EU accessibility legislation introduced a clear compliance deadline, the company treated it as both a regulatory obligation and a strategic move to improve product quality and inclusivity.
In this context, I led the end‑to‑end accessibility initiative as UX Lead, orchestrating efforts across teams and turning audit findings into concrete UX and engineering work, from updating the design system and component library to defining screen‑reader behaviours and localisation rules for every key flow. Day to day, I worked closely with Product, Engineering, QA, Legal, and Marketing and collaborated with external accessibility auditors to evaluate the products and guide remediation across all platforms.
Problem
Users with disabilities were effectively blocked: screen‑reader users could not complete key flows because of missing labels and unclear announcements; low‑vision users struggled with low contrast and small targets; keyboard‑only users encountered broken focus order; and complex layouts with inconsistent patterns increased cognitive load and confusion.
At a product level, accessibility issues were systemic: inconsistent components, missing ARIA and semantic structure, low‑contrast UI, weak focus management, unclear validation and error messaging, plus localisation problems that broke layouts or changed meaning across languages.
For the business, this created a tangible risk of non‑compliance with the EU Accessibility Directive, exclusion of users with disabilities, reputational damage around inclusivity, and higher support and operational costs driven by avoidable usability issues.
What I did
The accessibility initiative was guided by a few clear principles: treat accessibility as a default requirement, design systems instead of one‑off fixes, keep behaviour consistent across mobile and web, and invest in education so teams could own accessibility rather than depend on policing. Evidence from audits, real user impact, and assistive‑tech testing was used to prioritise what to fix first and where trade‑offs were acceptable.
To understand the baseline, I led a comprehensive audit with external specialists, combined with internal heuristic reviews, code‑level inspections, and hands‑on testing of key journeys with screen readers and other assistive tools. This work produced a detailed inventory of components and end‑to‑end flows that needed remediation, spanning design, content, and engineering.
From there, I ran several coordinated workstreams: updating the design system (colour tokens, components, semantics, interaction rules), specifying screen‑reader behaviour, focus management and error patterns for core flows, fixing localisation‑related issues, and creating clear guidelines for accessible design and UX writing. In parallel, I set up cross‑functional governance with Product, Engineering, QA, and Legal; introduced regular ceremonies to track progress; handled trade‑offs through explicit decision forums; and framed accessibility as an ongoing programme with strategy, roadmap, milestones, and success metrics rather than a one‑off checklist.
Solution
The existing design system already covered much of the accessibility foundation—hit areas, contrast, and core components were largely in good shape—so the focus shifted from fixing basics to closing gaps, standardising behaviour, and making accessibility systematic. Building on that 80% baseline, we refined colour tokens for edge cases, added consistent and more visible focus states, and tightened semantics and ARIA usage on complex components like tabs, carousels, and dropdowns to ensure predictable behaviour with assistive technologies.
At the flow level, work centred on making critical journeys reliably accessible end-to-end: onboarding was structured so screen‑reader users could move through forms with clear progress and context; payments, transfers, and profile management were aligned on labels, focus order, and error patterns; and authentication flows announced states and outcomes in a timely, consistent way. To embed this into everyday practice, teams received an accessibility checklist, reusable screen‑reader spec templates, updated Figma libraries, QA scripts, and a central documentation hub—turning accessibility from an ad‑hoc effort into a repeatable capability across products.
Outcomes
The accessibility initiative led to a clear drop in accessibility‑related bugs during QA as teams began using common standards and checklists, and external audit scores improved noticeably after the design system refinements and flow‑level fixes. Cross‑team handoffs became smoother thanks to clearer specs, shared templates, and predictable component behaviour, while support saw fewer issues tied to failed flows, opaque errors, or localisation problems.
Both external auditors and internal teams gave positive feedback on the clarity of the guidelines and the maturity of the overall approach. One of the most meaningful signals of impact was a public review in the app store from a disabled user who highlighted how usable the app felt—an immediate reward for the team’s efforts and a compass for how we should continue to design going forward.
What I learned
This work reinforced that accessibility is fundamentally a systems problem: fixing components and patterns scales impact far more than patching individual screens. Close collaboration with Legal and Compliance is essential to interpret regulations pragmatically and translate them into product requirements the teams can act on.
It also showed that lasting change depends on teaching and enabling teams, not centralising every decision within UX; clear governance, shared rituals, and alignment mechanisms are what turn accessibility from a side project into an integrated product practice. Designing with accessibility in mind from the start consistently led to cleaner UI, clearer structure, and better usability for everyone—not just compliance for a specific user group.
