Software Accessibility

Building Xerox's Software Accessibility Practice from Zero

The Challenge

In late 2024, Lexmark's software business was entering a new phase. Our cloud platforms had exponentially grown in the last decade, mobile applications were expanding in the app stores, and we were onboarding larger enterprise and federal customers than ever before. At the same time, the European Accessibility Act was about to take effect, bringing real legal exposure for software sold into the EU.

One problem: in a company that had always been hardware-first, no one owned software accessibility. Our products had never been accessibility-tested. No VPATs existed. Our development teams had never been trained. There was no reporting tool, no governance, no process. A decade of software development had shipped without a single formal accessibility review.

I recognized the gap, made the business case, and built the function.

The Solution

Over the following 18 months, I established Lexmark's (now Xerox's) software accessibility practice end to end — training, tooling, governance, and design system integration. Today I serve as the combined company's Software Accessibility Mandate Owner and co-hold a seat on the ITIC council. In 2025 I was awarded the company's Global Vision Champion Award for this work.

The Bottom Line: In the first year we back-tested all 15+ core software products, logged and began remediating hundreds of accessibility defects, closed nearly 300 accessibility bugs within our Polaris design system alone, shipped multiple products that followed WCAG 2.1 AA guidelines, and positioned the company ahead of European Accessibility Act enforcement.

How it Begun

Stumbling Upon the Gap

While updating our cloud software design system, I started researching accessibility to improve the components I was building. At the same time, a round of layoffs meant the company's single part-time accessibility contact (historically focused on hardware) had retired, and the responsibility passed informally to a hardware UX colleague. She recruited me to look into the software side.

What I found was a vacuum. When I asked teams across the company whether accessibility had ever been considered, the answers were blank stares, "I don't think we do that," or outright deflection. Only a handful of testers had ever performed any accessibility work, and the bugs logged had rarely been prioritized.

Two realities converged and made this urgent: our software was now reaching far more users than it ever had, and we were creeping more into federal and public usage of our software products and mobile applications. The European Accessibility Act was coming into force, and products in its scope without accessibility documentation would be exposed to real legal and commercial risk.

I knew I needed to become an expert, and fast. I'm someone who learns by going deep, so I went deep. I took the W3C software accessibility certification, worked through articles, podcasts, and videos until I didn't just understand the compliance requirements but could speak to the technical implementation behind them. By the time I walked into my first conversation with leadership, I wasn't asking for permission to explore the problem. I already had the strategy.

Making the Case to Leadership

Through dozens of meetings with managers and leadership across the software organization, I framed accessibility not as an ethical add-on but as a converging risk: regulatory exposure under the EAA, contract-eligibility risk for federal and enterprise pursuits that required VPATs, and a decade of accumulated compliance debt across mature products. The response I eventually earned was the one I needed: "We see this is a problem. Now what? How do we undo a decade of bad practices?"

I pitched a four-part strategy:

Educate developers, designers, and testers across all core products.
Back-test the existing product portfolio to understand the scope of remediation.
Remediate based on severity, prioritizing the highest-risk products first.
Produce VPATs for each remediated product.

Leadership green-lit the plan. I had no team, no budget, and no roadmap. That part was on me to figure out.

Building the Foundation

The Accessibility Avengers

To build the curriculum with real credibility, I recruited a cross-functional coalition of developers and testers who had either prior accessibility exposure or a genuine interest in the work. This group (I called them the Accessibility Avengers) shaped the training materials, vetted the resources, and became the internal evangelists who made adoption possible. They were the reason the practice could scale faster than one person could push it.

Training

Sending hundreds of developers through paid external training wasn't financially realistic. So I partnered with our internal SkillSoft team to build something homegrown: a curriculum designed specifically for front-end developers and QA testers, with curated bootcamps, practical exercises, and a clear set of resources and tools to help them get started.

Building the Tools

Several of the Accessibility Avengers volunteered their quarterly innovation sprint to co-build a custom accessibility reporting tool. The tool allows testers to log product performance against WCAG 2.1 AA guidelines, integrates directly with Azure DevOps for bug tracking, and generates formal Accessibility Conformance Reports for tested products. This single piece of tooling turned accessibility from a thing teams intended to do into something they could measure, prove, and ship against. It also gave leadership a portfolio-level view of accessibility progress, which made the continued investment case self-renewing.

WCAG reporting tool landing page — WCAG reporting tool – Landing page

Example of a test case in the WCAG reporting tool — WCAG reporting tool – example of a test case

Generated Accessibility Conformance Report — Accessibility Conformance Report

The Moment the Culture Turned

I ran a three-day workshop to bring it all together. The moment that changed everything came on day two: I brought in a developer from the Bluegrass Council of the Blind — a highly skilled developer in his own right, and someone who is almost completely blind. I wanted a speaker who could meet our engineering team at their own technical level, and he delivered. He answered their questions with both deep expertise and lived experience at the same time. Watching developers connect the human reality of their users to the actual code they wrote every day was the most valuable hour of the entire initiative. You could feel the room shift.

Embedding Accessibility at the Component Level

The highest-leverage move was the simplest: fix accessibility inside Polaris itself. Nearly 300 component-level bugs closed — contrast, keyboard interactions, ARIA labeling, focus management. When the library shipped, every team building on it inherited the fixes without doing a thing. That's the power of working at the system level.

Adoption & Impact

What followed surprised even me. Development teams began adding accessibility criteria to their Definition of Done checklists. Test teams adopted the reporting tool and began systematically back-testing legacy products. Within the first year, all 15+ core software products were back-tested, with hundreds of accessibility bugs logged and prioritized for remediation. The reporting tool expanded to cover mobile products. Multiple products shipped at close-to-WCAG 2.1 AA compliance — proof that the pipeline worked.

The clearest sign that it stuck: I used to field dozens of accessibility questions a week as teams adjusted. Today I field almost none. Some of the same developers who were initially skeptical are now advocating for accessibility improvements in third-party plug-ins and adjacent software our products depend on. The practice has outgrown dependence on me, which was always the goal.

After the Xerox merger, my mandate expanded to a much larger portfolio. My co-lead and I also delivered a guest lecture on accessibility across hardware and software products at the University of Kentucky School of Product Design — standing in front of a room of designers who were exactly where I had been a few years earlier, before I knew any of this mattered. Getting to be the person who plants that seed early, before they've shipped a single product without thinking about who might be left out, felt like the whole point.

Nora delivering a guest lecture at the University of Kentucky School of Product Design — University of Kentucky School of Product Design – Guest Lecture

Audience at the University of Kentucky accessibility guest lecture

What I learned

See the gap, build the function

The most important work is often the work nobody has been asked to do yet.

Influence is built layer by layer

W3C certification gave me technical credibility. The business case gave me a seat at the table. The Avengers gave me peer credibility. The workshop gave the work its human weight. None of it would have landed without the others.

Build for durability

A practice that only runs because one person keeps pushing it isn't a practice, it's a dependency. Everything I built here was designed to outlast me. That's the difference between a project and a capability.

The Full Story