Case study · Accessibility · GEP Worldwide
A global procurement platform had more than 6,000 accessibility violations. The real problem was not the number. We had no way to stop making more.
6,000-plus
violations at the start
Fewer than 14
after 18 months
80+
accessible components in Radiant
About 20%
faster turnaround, reported by developers
My role: Head of Accessibility and Design Systems, Nov 2022 to Jun 2026. I led a team across three countries.
The problem
GEP builds procurement software for some of the world’s largest companies. When I arrived, the platform carried more than 6,000 accessibility violations. Screen reader users could not finish core tasks. Keyboard users hit dead ends. The design team had no shared standard and no way to test their own work.
Clients had started asking hard questions. The answers were not good.
The team worked hard and still lost ground. Every new feature added problems faster than anyone could fix the old ones.
Three teams. Three countries. No common toolset and no common language for what “accessible” even meant. You cannot test your way out of a hole like that. You have to change how the work gets made.
The approach
We trained first and fixed second. Every designer took the W3C’s Digital Accessibility Foundations course, from the Web Accessibility Initiative and delivered through edX. We did this before we touched the backlog. It was real coursework, plus hands-on practice with the tools they would use every day: Color Contrast Analyzer, WAVE, Axe and SiteImprove.
We put the tools where the work happens. Designers check contrast and structure in Figma before handoff. Developers have accessibility checks in the build process, so problems get flagged before code merges. The style guide carries accessibility notes on every component.
We hired testers with disabilities. This is the part I am most proud of. Our testers use assistive technology every day. They test real scenarios with JAWS and NVDA, not simulations. A sighted developer running an automated scan will never find what they find.
We made fixing a daily habit. Bug Bash meetings happen every day, not once a quarter. Accessibility debt stops piling up, and developers learn why each fix matters.
We brought in outside eyes. We worked with third-party auditors, including Level Access and Deque, to verify compliance with ADA, WCAG, Section 508, CVAA, AODA and Mandate 376. We kept our Accessibility Conformance Reports current against the latest VPAT template.
We built AI into the pipeline. I built an accessibility testing agent with Claude Code, Playwright, Axe and Storybook. It checks components as they are built, so problems show up in minutes instead of quarters. The agent handles the repetitive scanning. The team handles the judgment calls.
The design system did the heavy lifting
Most of this work ran through the design system, because that is where you fix problems at the source instead of one screen at a time.
Radiant. My team built Radiant so accessibility was the default, not a choice. Every component shipped with the right contrast, focus states and semantics already in place. Designers stopped deciding whether to be accessible. The system decided for them.
Navigation. I led a full redesign of the navigation, the part of the product every person touches. A clear, logical, keyboard-friendly structure helps a screen reader user and a power user at the same time.
Dashboards. Clients would open a dashboard and not know where to look. We rebuilt the visual hierarchy so the most important information had the strongest presence on the screen.
The part most teams get wrong
Automation finds only about one-third of accessibility issues. The rest need a human. We could run Axe on every build and still ship a product that a blind person cannot navigate. The scan does not know your tab order makes no sense. It does not know that an error message is labeled correctly but says nothing useful.
That is why we hired testers who live with these tools, and why we met every day. The tooling buys you speed. People buy you the truth.
What I would tell another leader
Accessibility is not a testing problem. It is a design system problem, a hiring problem and a leadership problem.
You can hire an army of testers and file tickets forever. You will never catch up. The only way out is to make the accessible choice the easy choice, then make it the default. Build it into your system. Put people who use assistive technology on your team. Change how the work gets made.
The 6,000 number is not the interesting part. The interesting part is that we stopped making new ones.
Accessibility is a global obligation
Software crosses borders, and so do accessibility laws. I grew up in France, and I have watched accessibility get treated as a US checklist. It is not one. My practice is built on WCAG 2.1 AA, which international rules extend. France’s RGAA turns those guidelines into concrete tests and a measurable compliance rate. The European Accessibility Act, in force since June 2025, now puts those duties on private companies across the EU. These frameworks overlap, but they are not the same, and treating them as interchangeable is a common and costly mistake.
Want accessibility to be your default too?
hire.daveb@startide.net · LinkedIn · Back to accessibility work