Making accessibility everyone’s job
Accessibility was checked last, and the same issues kept coming back. A workshop, a checklist and earlier reviews fixed that, with no mandate.
Front-end engineer // Amsterdam
I write about the seam between design and front-end: accessibility, design systems and the habits that keep interfaces right.
I’m a front-end engineer at Rabobank in Amsterdam. I spend my days where design decisions turn into code, which is where most interface mistakes are made, and I champion accessibility across my department. This site is where I think in public: what works at that seam, what doesn’t, and what I would tell a team starting tomorrow.
01
Accessibility is not a final audit, it is where every component starts. I champion it across my department, and I write about making it a habit a whole team keeps, not the heroic effort of one specialist.
On the blog: “Making accessibility everyone’s job”
02
Interfaces drift when nobody looks after the system. I write about tokens, components and the agreements that keep a design file and a codebase saying the same thing.
On the blog: “Tokens are a contract, not a palette”
03
Speed is a feature people feel before they see it. I write about raising it in design and code review, while it is still cheap to fix, instead of optimising in a panic afterwards.
On the blog: “The 100 ms budget”
04
Design intent should survive the handoff. Most of my work happens in that gap, and most of what I write comes from it: the mistakes that are cheapest to catch before a line of code exists.
On the blog: “The cheapest bug is the one in the mock-up”
Blog
Essays on accessibility, design systems and working between design and front-end. Practical, opinionated and drawn from real projects, with a new one roughly once a month.
Accessibility was checked last, and the same issues kept coming back. A workshop, a checklist and earlier reviews fixed that, with no mandate.
Missing states cost minutes in a design review and a sprint in production.
A colour token is a promise about meaning, not a hex value: treat it like code.
Latency targets a team can hold, set in design review, not after a bug.