Skip to content Leigh Bertelsen

// featured work · netcompany banking services · 2023 to present

Accessibility implementation

How a large React codebase got automated accessibility enforcement, layer by layer, without grinding the team to a halt.

50+
nordic financial institutions
2M+
end users on the platform

I'm responsible for a large React codebase serving banking clients, where accessibility compliance is a legal requirement under the EU Accessibility Act. When I came on board, the project had thousands of existing accessibility violations and no automated enforcement to prevent new ones from being introduced. With a platform spanning 50+ Nordic financial institutions and over 2 million end users, the cost of getting it wrong was real, and the cost of treating it as a checkbox was steeper still.

The constraint was that I couldn't just switch on linting and fail the entire CI pipeline. That would have blocked every developer immediately. So I designed a layered system that enforced quality on new and touched code without grinding work to a halt.

The first layer is IDE linting using eslint-plugin-jsx-a11y, which flags accessibility issues in native HTML elements as developers write code. But linting alone has a gap: it analyses source code statically and doesn't know what custom components like an image cropper actually render in the DOM, so it can't catch issues inside them.

To cover that gap, I wrote a script that auto-generates jest-axe unit tests for existing components, and updated the component scaffolding tool so new components get accessibility test files by default. These tests render the full component tree and inspect the actual DOM output, which catches issues inside custom components the linter can never see.

The third layer is a CI gulp task that runs accessibility linting specifically on touched files and throws an error on violations. Untouched files with existing errors are excluded for now, so the pipeline stays unblocked while new code is held to a clean standard.

Finally, I added @axe-core/react to run runtime accessibility checks in non-production environments, so developers get real-time browser console feedback as they work, even after interactions or dynamic updates.

My job was to ensure the platform met the standards defined by the EU Accessibility Act. I kept current through sessions and conferences hosted by Dansk Sikkerhedsstyrelsen and the IAAP, then translated all of it into something the team could actually act on. Not the legalese version, the version that means "this button needs a visible focus state" and "this color pair fails 4.5:1."

The result is that new accessibility violations can no longer reach production undetected, the existing backlog is being addressed incrementally, and the whole thing is documented in a wiki so the team can maintain it without me.

The part I'm most proud of is that none of this was a "campaign." There was no accessibility week, no posters. The standards just got built into the work, the way other quality concerns do. That's the version of accessibility that lasts.

Her passion for accessibility isn't just talk; she truly builds with everyone in mind.
— Elvis Carlos developer, Netcompany Banking Services