A legal accessibility deadline could have become a checklist of screen fixes. I spent it on the system those screens sat on.
YEAR
2025
COMPANY
Verimi
STAtus
Web: shipped. iOS: built, not launched. Android: designed, not started.
Accessibility
Design Systems
Responsive web
Regulated identity
Systems thinking
Accessibility and consistency built into one responsive web layout, with the components and page types designed to carry the same standard to the mobile apps. Regulated identity product (verification, QES, authentication).
I designed the layout, defined the component behaviour to match the design-system components, wrote the documentation for web and the apps, and moved the screens over one by one: ticket, acceptance criteria, design review, then QA. The team was frontend only.
Treated accessibility as a system constraint, not a feature. Consolidated 30-plus ad-hoc web layouts into one configurable, responsive layout component. Designed the page types and components to carry the same standard to iOS and Android.
On web, one configurable responsive layout powered 9 flows and more than 100 screens. Frontend and QA reported that build and test time dropped by about half. The same standard was carried into the iOS app, which was built but never launched. Android was not started, because mobile engineering was never resourced.
German accessibility standards. Regulated flows (identity, QES). Frontend-only team. Component definitions split across more than one source that did not stay in sync.
The problem
In Germany, accessibility for consumer-facing digital services became a legal requirement in June 2025. The easy reading was a to-do list: audit the screens, fix what fails, move on.
The real issue sat under the screens. On web, the product had drifted into more than 30 ad-hoc layouts, added over time with no shared rule, and accessibility was fixed wherever someone noticed a problem, so every fix was re-argued and re-checked at the next release. Underneath that, the same components behaved differently from one place to the next. Forms, validation and error handling each worked one way in one screen and another way elsewhere. Validation fired at different moments, errors showed up in different ways, and feedback did not match. Accessibility was not built into the components. They were defined by how they looked, not by how they behaved, so it lived as an implicit expectation that everyone read slightly differently.
You cannot meet an accessibility standard screen by screen in that setup. Fix one screen today, and it drifts again at the next release.
So the mission was to fix it at the system level: one web layout and one standard, plus the components and page types to carry that standard to the apps.
The same component behaved differently screen by screen. Accessibility cannot be consistent where behaviour is not.
The decision: fix screens, or fix the system
The deadline forced a choice about where to spend the effort.
One option: treat the deadline as a checklist. Audit the screens, close the findings, report done. It looks finished by the date. It also means every new feature brings the same gaps back, because nothing underneath has changed.
The other: treat accessibility as a property of the system, and use the legal requirement as the reason to standardise work that had never had a project or a budget of its own. A legal requirement is hard to deprioritise. A designer’s case for tidiness is easy to deprioritise. The requirement gave the consolidation a reason it could not lose.
I took the second. The cost was real: no quick wins to show, in an environment where accessibility carried no revenue attribution and every priority was a negotiation.
What I did
I worked on three axes, all pointed at the same standard.
Layout. I designed one configurable, responsive layout component and consolidated the 30-plus ad-hoc web layouts onto it.
Components. I wrote one behaviour definition for each web component: focus order, when validation fires, how errors are announced, what feedback the user gets. I designed the same definitions for the app page types, so the apps could follow the same standard.
Copy. I standardised the tone and wording across the 9 flows, in plain language, so the content met the same bar as the layout.
Then I moved the screens across, one at a time. For each one I wrote the ticket, set the expected behaviour and the acceptance criteria, ran the design review once it was built, and only then passed it to QA. Consistency was enforced at the point of handover, not hoped for after it.
I also wrote the documentation for how the components and page types should be built and behave, for web and for the apps, so teams had a reference instead of a person to interrupt.
The layout rules every screen was moved against.
One responsive web layout: 9 flows and 100+ screens across desktop and mobile browsers.
Consistency enforced at handover, not hoped for after it.
The work also raised questions it could not answer on its own: how the components stay in sync across products, and how they should be versioned. That is a separate piece of work.
What changed
On web, one configurable responsive layout powered 9 flows and more than 100 screens. Frontend and QA reported that build and test time dropped by about half, because a component built once behaved the same everywhere it appeared. Component behaviour converged where the definitions landed, handovers stopped regenerating the same questions, and accessibility became a defined, shared standard rather than an implicit one. The documentation outlived the features it was first written for.
Honest limits. The web layout shipped. The iOS app was built to the same standard but never launched, and Android was not started, because mobile engineering was never resourced, so the accessibility work never reached users on either app. The team was frontend only, so the changes were bounded to the surface. Accessibility never got its own centralised ownership, so adoption moved with each team’s capacity. This was incremental, not a single-launch transformation.
What I would do differently
Push earlier for the mobile capacity, or for an explicit decision on app scope, so the standard I designed could ship on every platform instead of stopping at the design stage. I would also set the ownership and the success metrics up front, rather than letting the value prove itself after the fact, so the work was measured against engineering efficiency and compliance readiness, not only feature delivery.
Closer
In regulated, multi-platform products, the design work that lasts is the infrastructure that makes change repeatable, not the individual screens. The accessibility requirement was the constraint that finally justified building it. On web it shipped. On iOS it was built and waited for a launch that resourcing never reached.