How to build an accessibility program from nothing

When someone asks how to "build an accessibility program," they usually mean: we have no process, some accumulated debt, a vague executive commitment, and no one with clear ownership. Where do you start? The answer most people expect is a maturity model, a phased roadmap, a training curriculum. Those things come later. What actually moves the needle first is something more tactical: find the part of your process that produces the most accessibility bugs, and fix just that.

Every company has a different version of this bottleneck. Sometimes it's handoff: designs arrive at engineering with no accessibility specs and engineers make guesses. Sometimes it's component libraries, where a handful of shared components without keyboard support spread that bug across every surface that uses them. Sometimes it's no one testing with a screen reader until an audit forces the issue. The shape of your debt tells you where to intervene.

The audit is not where you start

This contradicts the conventional advice, so it's worth unpacking. Audits are expensive, and the output (a VPAT or a findings report against a crawl of your product) tends to get treated as a to-do list rather than a diagnosis. You fix the items on the list and feel done. The process that generated those issues in the first place is unchanged.

A short internal test is more useful at the start. Pick your five most trafficked flows. Turn on a screen reader, navigate with only a keyboard, and take notes. You're not producing a compliance report. You're learning where your product is structurally broken. The goal is to identify the failure categories that appear repeatedly: missing focus management across every modal in the product, unlabeled icon buttons in every table row, color-only error indicators on every form.

Those categories point to process gaps, which are fixable at the source. Fixing them at the source means they stop accumulating.

What to do with components

If your product has a shared component library, the most efficient accessibility work is making those components correct. A button with a broken keyboard interaction pattern represents not one bug but hundreds, everywhere that button appears. A dialog component with correct focus management fixes every dialog in the product.

This also tends to be more achievable than product-level remediation, because component work is contained. You're changing a finite set of files, with clear ownership, and the fix propagates. Product teams usually don't have to be involved. You don't need cross-team coordination.

Start with the components that represent the highest surface area: buttons, inputs, links, modals, dropdowns. The WAI-ARIA Authoring Practices Guide documents the expected keyboard interaction for all of these. Map your current behavior against those patterns and note the gaps.

Who owns this

One of the reasons accessibility programs stall is that ownership is ambiguous. Design thinks engineering owns the implementation. Engineering thinks design should have specced it. QA waits for a test plan. Product says it wasn't in the requirements.

The program needs someone who can cut across all of those and be the person who is specifically responsible for driving the work. This doesn't have to be a full-time accessibility engineer. At most companies it starts as someone with an interest who's been given explicit authority: to file bugs, to block releases, to add accessibility to the definition of done.

The explicit authority part matters. Without it, the person is just an advocate, and advocacy without organizational authority doesn't move roadmaps. The teams where I've seen this work have had a director or VP who said, in a room with engineering and product, that accessibility is a release criterion. That statement changes the calculation for everyone downstream.

Getting accessibility into the definition of done

The phrase "definition of done" is overloaded, but the concept is useful: what does a piece of work need to meet before it ships? If accessibility isn't on that list, it's optional. It will be deprioritized when things are tight, which is always.

Adding accessibility to DoD doesn't mean every PR requires a full audit. It means specific, checkable things: does every interactive element have a visible focus state? Does every image have alt text? Does the component work with a keyboard? Does it have the correct ARIA role?

These questions can be answered in a few minutes by an engineer who knows what to look for. The bottleneck is usually that they don't know what to look for, not that they lack the time. A short internal guide covering the things to check before closing a ticket handles most of the ground without requiring expertise.

Making the audit useful

Once the basic process gaps are closed, a formal audit against WCAG 2.1 AA becomes more valuable. You're measuring residual issues rather than systemic ones, which is a better use of the findings. An external audit also carries weight internally that an internal test doesn't. "An external accessibility expert found these issues" moves tickets differently than "I found these issues in a QA pass."

The output of the audit should feed a remediation backlog with estimated effort and business priority. Not every finding needs to be fixed immediately; some will be complex and low-traffic and can be scheduled. What matters is that they're tracked and assigned, not sitting in a PDF.

The mistake I've seen teams make is treating the post-audit remediation as the end of the program rather than the reset point. After remediation, the goal is to not accumulate new debt at the old rate. That means the process changes, not just the backlog.

Where programs actually succeed

The programs that stick tend to have two qualities that don't show up in maturity models. First, someone in a leadership role who treats accessibility failures as product quality failures, the same way they'd treat broken functionality or a privacy incident. Not as a compliance risk, but as a quality problem that reflects on the team's work.

Second, the team has a shared mental model of who they're building for. Not "people with disabilities" as an abstract category but specific users with specific contexts: someone navigating with a keyboard because of a hand tremor, someone using a screen reader because they're blind, someone who can't complete a time-pressured flow because they process information more slowly. The teams that sustain an accessibility practice have made those users real to them.

The tooling, the audits, the checklists are legible and easy to point to. They're also the parts that can exist without the program actually working.