Designing accessibility as a system

Raising the baseline in regulated digital products

Led a cross-product accessibility initiative in a regulated digital identity ecosystem, using accessibility as leverage to reduce complexity and establish a scalable design-system baseline.
The work shifted accessibility from reactive fixes to shared standards, improved cross-platform consistency, reduced development and testing effort, and informed a company-wide strategy focused on simplification and long-term scalability.

At a glance

Role

Product Designer

Context

Regulated digital identity and health-adjacent products

Scope

Cross-product · Web, iOS, Android

Key constraints

WCAG compliance · regulatory requirements · legacy components · limited backend flexibility · constrained engineering capacity

The problem

Accessibility was not an explicit product or engineering concern and was addressed inconsistently, mainly through late-stage visual checks handled within the design team.
With new accessibility legislation and operation in regulated identity and health-related contexts, this created direct compliance and commercial risk.

At the same time, the product ecosystem lacked shared patterns and a design system, resulting in duplicated work and increasing complexity across critical user journeys. Accessibility could therefore not be addressed through isolated improvements and required a system-level approach.

What I owned

  • Defined accessibility priorities at system level

  • Translated WCAG requirements into practical, reusable design standards

  • Aligned design and engineering on shared accessibility patterns

  • Influenced cross-product decisions without direct authority

What changed

  • Accessibility embedded into shared components and layouts

  • Consistent patterns across web, iOS, and Android

  • Reduced development and testing effort through reuse (based on engineering feedback)

  • Lower compliance risk and improved readiness for regulated partnerships

  • Direct input into a company-wide strategy focused on simplification and reducing long-term product complexity

Why this matters

This work demonstrates how accessibility and regulation, when treated as system constraints rather than checklists, can be used to reduce complexity, improve product quality, and create more scalable, resilient digital products.

↓ Full case

The problem

Accessibility was not an explicit product or engineering concern and was addressed inconsistently, mainly through late-stage visual checks handled within the design team.

With new accessibility legislation and Verimi’s role in regulated identity and health-related products, this created a direct compliance and commercial risk, particularly for partner products required to meet full accessibility standards.

At the same time, the product landscape lacked shared patterns and a design system, resulting in inconsistent layouts, duplicated work, and increasing complexity across critical flows.

Accessibility could therefore not be addressed through isolated improvements. It required a system-level approach that established a shared baseline and reduced complexity across products and platforms.

Why this was hard

Accessibility improvements had to be delivered under significant technical, organizational, and prioritization constraints.

While strategically critical, the initiative did not directly generate revenue. Its value lay in compliance, risk mitigation, and market readiness, which meant accessibility work was frequently deprioritized in favor of delivery-focused initiatives.

Technical constraints further limited solution space. Backend changes were largely unavailable, requiring accessibility improvements to be implemented primarily on the frontend — even when this led to suboptimal but compliant solutions, such as continuing SMS-based flows.

The product ecosystem also lacked an independent design system. To reduce risk under limited capacity, components were reused from another product, introducing constraints around ownership, versioning, and structural change.

Finally, accessibility had to be addressed consistently across web, iOS, and Android, often under strict client and contractual requirements. This required pragmatic, cross-platform solutions that balanced compliance, feasibility, and long-term reuse within existing technical boundaries.

Strategy and approach

Given regulatory pressure, limited capacity, and a fragmented product landscape, the goal was not to fix individual accessibility issues, but to raise the baseline in a way that would scale.
The strategy focused on reducing complexity, creating shared standards, and embedding accessibility into the system rather than treating it as a parallel initiative.

1. Treat accessibility as a system

Given regulatory pressure, limited capacity, and a fragmented product landscape, the goal was not to fix individual accessibility issues, but to raise the baseline in a way that would scale.
The strategy focused on reducing complexity, creating shared standards, and embedding accessibility into the system rather than treating it as a parallel initiative.

2. Combine accessibility and design system work

Accessibility efforts were intentionally aligned with the creation of a design system and shared layout rules.

Accessible components, spacing rules, and responsive layouts made accessibility reusable by default, rather than reimplemented per feature.

This improved consistency while allowing teams to move faster under constrained capacity.

3. Optimize for reuse under technical constraints

Given limited backend flexibility and the reuse of components from another product, the strategy prioritized solutions that worked within existing boundaries.

Decisions focused on:

  • minimizing one-off solutions

  • keeping patterns understandable and repeatable

  • ensuring safe reuse across platforms

This reduced long-term maintenance risk, even when short-term compromises were required.

4. Use accessibility as leverage to reduce complexity

Accessibility created an opportunity to revisit long-standing product issues that had previously been deprioritized.

Flows were simplified, variations reduced, and visual noise removed to support clarity and accessibility.

“Essential” was defined explicitly: features had to be necessary for core user tasks, legally required, or commercially viable. Anything outside these criteria was challenged or removed.

Rather than adding rules, the strategy focused on removing what was not essential, aligning accessibility improvements with broader product and business goals.

5. Collaborate closely across platforms

Accessibility decisions were developed in close collaboration with web, Android, and iOS teams, often through dedicated working sessions.
Design decisions were continuously validated against implementation realities, enabling pragmatic trade-offs without losing accessibility goals.

Outcomes and impact

Reduced delivery and testing effort

Reusing accessible components and standardized layouts made development and QA more predictable.

Engineering feedback indicated a significant reduction in development and testing effort for shared flows and components.

Improved cross-functional alignment

Accessibility standards created a shared reference point across design, engineering, QA, and product, reducing ambiguity and late-stage rework.

Enabled strategic simplification

Accessibility supported broader decisions to simplify flows and challenge low-value features based on user necessity, legal requirements, and commercial viability.

This work directly informed a company-wide product strategy focused on simplification and keeping only what is essential for users and the business. While implementation is planned for 2026, the accessibility mission laid the structural and conceptual foundation.

Strengthened compliance and market positioning

Proactively addressing accessibility reduced compliance risk and improved readiness for tenders and regulated partnerships. Accessibility shifted from a perceived cost to a strategic capability.

The accessibility mission led to a clear shift from reactive fixes to a shared, system-level baseline.

Raised accessibility baseline

Accessibility was embedded into components, layouts, and shared patterns, improving consistency across web, Android, and iOS.

Reflection

Accessibility cannot succeed as a parallel initiative. It becomes sustainable only when embedded into systems, standards, and decision-making.

Under tighter constraints, I would push earlier for clearer ownership and shared success metrics that value reduced compliance risk and long-term development efficiency — not only short-term delivery.

Most importantly, this work reinforced that regulation does not have to limit product quality. When approached deliberately, it can become leverage for simplification, focus, and better design decisions.