Accessibility

Making a product accessible, sprint after sprint

Product DesignAccessibilityFront-endSaaS B2B

I led the WCAG 2.1 AA compliance of a B2B SaaS product's web interfaces used internationally. From business case to front-end implementation, through prioritization and pattern documentation.

The trigger

An audit revealing the gap with standards

The platform had no structured accessibility approach on its web interfaces. An external audit revealed non-conformities on level A and AA criteria: insufficient visible focus, missing semantic relationships, form fields without descriptions... The product was below the standards expected by key enterprise accounts.

The argument that unlocked everything

Turning a constraint into a commercial criterion

Accessibility wasn't on the roadmap. What moved the needle was a concrete business risk: enterprise clients conditioning their renewal on WCAG AA compliance, and a public sector market increasingly demanding on this point. The topic shifted from technical constraint to commercial criterion. It was by framing the problem in terms of client risk that the initiative earned its place on the roadmap.

The prioritization method

Severity crossed with usage frequency

Facing the volume of non-conformities, I set up a cross-prioritization matrix: WCAG severity on one side, usage frequency of affected screens on the other. The principle: fix first what blocks people with disabilities the most on the most frequent journeys, to show quick results and maintain momentum.

High usage
Medium usage
Low usage
Critical
P1
P1
P2
Major
P1
P2
P3
Minor
P2
P3
P4
P1 — Immediate
P2 — Priority
P3 — Planned
P4 — Backlog

The implementation

Each fix becomes a reusable pattern

I took direct ownership of front-end fixes on the web client. Rather than fixing case by case, each fix became a documented, reusable pattern for devs on similar problems. Semantic HTML, focus management, contrasts, ARIA: each sprint advanced the compliance rate and reduced dependency on a single person.

Left: errors signaled only by color, no labels or descriptive messages. Right: each field has a visible label, a specific error message and a clearly identifiable focus.

What it changed

Accessibility integrated into the dev process

The goal wasn't to check a box. It was to establish accessibility as a team reflex. By the end of the mission, WCAG criteria were part of the dev process without waiting for a design review. The same goal as a design system: making quality self-sustaining.

By the end of the mission, the majority of main journeys were WCAG AA compliant.

WCAG AA compliance
validated by external audit

This mission confirmed that accessibility is managed like any product initiative: with clear prioritization, solid business arguments, and a progressive implementation that leaves lasting habits within the team.

The remaining cases involve secondary screens, less exposed to people with disabilities, and will be brought into compliance progressively as these components are redesigned.

Drag, click, explore

For the full experience, switch to desktop