Rebuilding an enterprise suite without breaking it.

Cybersource is the platform businesses use to run their payments: transaction search, reporting, fraud rules, recurring billing, user administration, the virtual terminal. It had been built by a lot of teams over a lot of years, and almost none of it had been built with a screen reader or a keyboard in mind.

What an audit of a suite like that turns up isn't a list of bugs. It's an accumulated default. Data tables you couldn't move through with a keyboard. Custom dropdowns built out of divs, invisible to assistive technology. Error states carried entirely by red text. Focus that walked into a modal and never came back out. Labels that existed visually and nowhere a browser could find them.

Programs like this usually run as a compliance exercise. Someone audits, files tickets, the tickets get closed, the product passes, and the next screen built after the program ends is exactly as inaccessible as the one before it. That version satisfies the requirement and changes nothing about how the product gets made. The question I was actually interested in was how a team stops reintroducing the same violations the moment the program is over.

This was the hardest call on the program, and I made it early and then held it. The suite looked dated, and fixing accessibility meant touching nearly every screen in it, which is precisely the moment a designer wants to modernize. I didn't.

No new visual language, no reorganized navigation, no improved flows, no moved buttons. The reasoning was concrete: these are tools businesses use all day, and the folks using them have muscle memory. A finance team reconciling transactions doesn't want a better experience on a Tuesday. They want the screen where it was. Anything we changed about the interaction model would have arrived as a support ticket, and enough support tickets would have ended the program.

That cost something real. I left genuine usability problems in place and said so out loud, because they were a separate piece of work with a separate case to make. A few of the textbook-accessible patterns got rejected for the same reason: the ideal version of a control changed how it behaved, and the clumsier version preserved the workflow. I took the clumsier version.

An audit of a suite this size produces a document nobody can act on. So I stopped treating the findings as a backlog and started treating them as evidence of a much smaller number of underlying problems. The issues resolved into a short list of recurring interface patterns: the data table, the filter set, the modal, the form field and its error, the date range picker, the multi-select, the status indicator, pagination, the tab set, the navigation tree.

Each one got solved once. Keyboard model, focus management, roles and names, states, announcements, contrast, error handling, all decided at the pattern level. Every instance across the suite then inherited the solution. That's what made the arithmetic work, and it meant that when an engineer hit a case a pattern didn't cover, we were fixing one definition instead of negotiating one screen.

A pattern that lives in a designer's head gets built as whatever the engineer guessed. So I changed what a handoff was on this program. Every screen carried accessibility annotations as a first-class layer: tab order drawn onto the screen, the accessible name for every control, roles and states, which regions announce changes and what they say, what each error message reads as, what happens to focus when a dialog opens and where it goes when it closes.

That removed the guessing, which is where most accessibility defects actually come from. It also moved the conversation with Engineering from “this fails 2.4.3” to “focus goes here next,” which is a conversation an engineer can act on in an afternoon.

This was not an audit handed to Engineering. The UI engineers knew the codebase and its constraints far better than I did, and a real share of the patterns were shaped by what they told me was achievable without a rewrite. I set the standard. They told me where it would hold and where it wouldn't, and what shipped was the version both sides could defend.

The program had an end date. Accessibility doesn't. So the last piece of the work was making sure the standard outlived it: documented patterns, annotations as the default deliverable, an accessibility review step in the delivery process with an owner who wasn't me, and walkthroughs for the designers and engineers who'd build the next screen.

The clearest evidence it held is where it turns up later. When I moved to Digital Acceptance, I argued for moving Unified Checkout onto Visa's Nova design system partly on accessibility grounds: accessible behavior should be inherited from a shared component foundation, not rebuilt and revalidated screen by screen. That's the Cybersource lesson restated as a product strategy. I learned it by doing the expensive version first.