Running an audit on an existing app

You've inherited a five-year-old app, or you've been told "we should do an a11y review," or a customer complaint just made it visible to leadership. The codebase is large; the backlog is going to be larger. The skill in front of you isn't finding issues — that part you already know — it's deciding which to fix in what order, and writing it up so the rest of the team can follow.

This lesson is process-heavy. It's the move that turns audits from "we found a thousand things" into "we shipped these eight in the next sprint."

Scoping the audit

A good audit names exactly what it does and does not cover. A short rubric:

• Pages or flows, not "the app." A first-time audit might be: home, sign-up, the primary task, settings, and one billing page. Five well-audited pages beat thirty half-audited ones.
• Devices and AT. Pick a small concrete combination: keyboard on Chrome desktop, VoiceOver in Safari on macOS, NVDA on Windows. Add mobile if it's a high-traffic platform.
• Conformance target. "WCAG 2.2 AA" is the most common. Write it down — it pins what you're measuring against.
• Exclusions. Explicitly list anything you're not auditing: the marketing site, the admin panel, third-party widgets. Otherwise stakeholders assume the audit covers them.

The priority matrix

Each finding gets three scores. The product is its priority.

• Impact (1–3). How badly does this hurt a user who hits it? 1 = inconvenience; 2 = workaround needed; 3 = blocked, can't complete the task.
• Frequency (1–3). How many users hit it, how often? 1 = edge-case page; 2 = common page; 3 = on every page (e.g. site-wide nav, layout shell).
• Difficulty (1–3, inverted). How easy to fix? 1 = trivial; 2 = significant; 3 = needs a redesign or vendor change. Lower is better. Some teams flip this to "ease" so multiplication still goes up — pick a convention and stick to it.

A priority score = impact × frequency × (4 − difficulty). High score = do first.

| Impact | Frequency | Difficulty | (4 − diff) | Score | |---|---|---|---|---| | 3 (blocker) | 3 (every page) | 1 (trivial) | 3 | 27 | | 3 (blocker) | 2 (common page) | 2 (significant) | 2 | 12 | | 2 (workaround) | 3 (every page) | 1 (trivial) | 3 | 18 | | 1 (paper cut) | 1 (edge case) | 3 (redesign) | 1 | 1 |

The first row in this table is the kind of finding you fix this afternoon: it blocks every user, on every page, with a one-line fix. The last row goes on a long-term wishlist — small impact, rare, expensive.

Writing the report

A report nobody reads is a report nobody acts on. Aim for short, actionable, and skimmable. The skeleton:

1. Executive summary. Three bullets, no jargon. "We audited five pages against WCAG 2.2 AA; we found 47 issues; 8 are blockers we recommend fixing this sprint."
2. Scope and method. Pages, devices, AT, what tools you used (axe, manual keyboard, VoiceOver, NVDA).
3. Findings table. Each row has: ID, page, summary, WCAG criterion, impact, frequency, ease, priority score, recommended fix.
4. Top blockers, with screenshots. The 5–10 highest-priority issues, each on its own page with a screenshot, a "what's wrong," "who it affects," and "how to fix."
5. Patterns. What you noticed across findings — "no focus indicators on any custom button," "all dialogs miss aria-modal." Pattern fixes are usually cheaper than per-instance fixes.
6. Backlog. Everything else, ranked by priority score.

A finding template that pays for itself:

ID: A11Y-014
Page: /checkout/review
WCAG: 2.4.7 Focus Visible (AA)
Severity: Critical (impact 3 × frequency 3 × ease 3 = 27)

What's wrong:
The "Place order" button has `outline: none` with no replacement
on focus. Sighted keyboard users cannot tell when the button is
focused before pressing Enter.

Who it affects:
Anyone using a keyboard, screen reader, or screen magnifier.

How to fix:
Remove the `outline: none` rule on `.btn-primary`, or add an
explicit `:focus-visible` style with at least 3:1 contrast.

Repro:
1. Tab from the order summary
2. Land on "Place order" — focus indicator is invisible

Sequencing fixes

Once the matrix is done, sequencing is mostly common sense, with three rules:

1. Pattern fixes before instance fixes. If 14 findings all stem from "we don't apply focus styles to custom buttons," fix the pattern first. The 14 individual tickets close as a side effect.
2. Layout shells before pages. A landmark fix in the global layout often clears one finding on every page. Easy multiplier.
3. Component library before product code. If your "Button" component has the bug, fix it once in the library; every consumer benefits without a rewrite.

The best three-month plan I've ever shipped looked like:

• Week 1: pattern fixes — focus rings, heading hierarchy in the layout, landmarks.
• Weeks 2–3: top 10 blockers, manually verified.
• Weeks 4–8: backlog cleared in priority order, batched by component.
• Week 9–12: regression suite — axe in CI, jest-axe per component, a small Playwright a11y spec per page.

That sequence ends with the suite acting as your guard for the next year.

Talking to stakeholders

Audits get killed in the last meeting, not the first. A few moves that help:

• Frame in user terms, not standards. "30% of our keyboard users can't complete checkout" lands harder than "we don't conform to WCAG 2.4.7."
• Offer scoped commitments. "Eight blockers this sprint, 47 over the next quarter" beats "fix everything." The latter is rejected by default.
• Tie to existing roadmap. If checkout is being rebuilt anyway, batch the a11y fixes into that work — much easier to fund.
• Show progress. Re-scan after each sprint, share the score. Going from 78 to 92 over a quarter is a real story.

Check yourself