You can run a flawless accessibility audit and have nothing happen, because the audit lived in your head, or in a Figma comment thread, or in a Slack message that scrolled away. The audit is not the deliverable; the report is, and the report only works if it lands on an engineer's desk in a form they can pick up and act on without a meeting. This lesson takes the findings from the whole chapter - contrast, focus, target size, alt-text, and motion - and compiles them into one engineering-ready accessibility report with severities, owners, Figma frame references, and remediation effort estimates. You leave with a publishable A11y Findings Report, the capstone artifact of the accessibility chapter, built so that the work you did to find the problems actually results in the problems getting fixed.

The Audit That Changed Nothing

Start with the failure this lesson prevents. A diligent designer spends a day auditing a flow. They find low-contrast text, focus rings that vanish behind a sticky header, 16-pixel tap targets, charts with visual-only alt-text, and a transition that ignores reduced motion. They are right about all of it. They leave comments in Figma, mention a few items in standup, and feel they have done accessibility. Three sprints later the flow ships with every one of those failures intact, because the comments were never triaged, standup forgot, and nobody owned anything. The audit was real work that produced zero fixes, which is the same as not auditing at all from the user's perspective.

The problem was never the auditing; it was the handoff. Engineering acts on tickets with owners, estimates, and clear acceptance criteria, not on scattered comments and verbal mentions. An accessibility finding that is not in the form engineering works with is a finding that does not get fixed. The entire value of the report is that it translates your findings into the unit of work an engineering team actually executes, so the fixes enter the same flow as every other piece of work and get done. This lesson is about that translation.

What an Engineering-Ready Report Contains

A report that engineering will act on has a specific anatomy, and every element of it exists to remove a reason the finding might be ignored. Each finding in the report carries five things.

The Five Elements of a Finding

1. The finding, as an observed fact with its criterion. Not "this looks low contrast" but "Body text on the dashboard summary card measures 3.8:1 against its background; WCAG 1.4.3 requires 4.5:1." The criterion makes it non-negotiable and the measurement makes it objective, so it cannot be argued down to a matter of opinion.
2. Severity. A clear severity level (critical, high, medium, low) based on user impact and blast radius, so engineering can sequence the work. A focus failure that blocks keyboard users from completing checkout is critical; a low-contrast helper text on a rarely-seen settings page is medium. Severity is the field that turns a flat list into a plan.
3. Owner. Who is responsible for the fix. Unowned findings are unfixed findings; the report names a team or person for each, even if that assignment is provisional and engineering re-routes it, because a finding with no owner is a finding everyone assumes someone else has.
4. Location, as a Figma frame reference (and code location where known). The exact frame and element, so the engineer goes straight to it. "Frame: Checkout-Step-2, element: Continue button focus ring" beats "the checkout has a focus problem" by the entire cost of the hunt.
5. Remediation effort estimate. A rough size (S/M/L, or hours) for the fix, so engineering can plan capacity and so the easy high-impact wins surface. A one-line token change that fixes contrast across the app is a different planning object than a focus-management refactor, and saying so helps the team sequence.

Plus, for each finding, the fix: the specific change that resolves it, ideally as a design-system token or component change so it resolves everywhere at once. A finding without a fix is a problem report; a finding with a fix is a ticket.

The audit finds the problems. The report is what makes them get fixed. A finding that is not in the form engineering works with - severity, owner, location, effort, fix - is a finding that does not get fixed, no matter how correct it is.

Compiling the Five Audit Types Into One Report

The chapter produced five kinds of findings, and the report unifies them. The contrast audit gave you ratio failures with frame coordinates. The focus, target-size, and motion audit gave you operational failures (focus obscured, drag-only, sub-24-pixel targets, motion ignoring reduced-motion preferences). The alt-text audit gave you content failures (decoratives described, charts conveyed by appearance, redundant prefixes). These are different in character - some are measurements, some are observed behaviors, some are content - but in the report they share one structure, because engineering does not want five different formats; it wants one list it can triage.

Normalize them. Every finding, regardless of type, gets the same five elements plus a fix, and a type tag (contrast, focus, target-size, alt-text, motion) so related fixes can be grouped. Grouping matters: if six findings are all "below 24-pixel target size" caused by the same icon-button component, the report should surface that they share a root cause and a single component fix resolves all six, which changes both the effort estimate and the priority. A good report does not just list forty findings; it reveals that the forty are really twelve root causes, several of which are one-line system fixes. That synthesis - from symptoms to root causes - is the judgment the designer adds on top of the raw findings, and it is what makes the report a plan rather than a pile.

Using AI to Compile, Without Letting It Own the Judgment

The compilation itself - taking raw findings and formatting them into a consistent, well-structured report - is exactly the kind of transformation a model does well, and you should use it. Feed the findings to Claude with a structured prompt: here are the findings with their criteria, measurements, and locations; produce a report with these columns, grouped by severity and root cause, with effort estimates. The model is good at the formatting, the grouping by stated category, and the consistent phrasing, which is genuine drudgery that would otherwise eat an hour.

What the model does not own is the judgment that makes the report a plan: the severity assignments (which require knowing your users and your product's critical paths), the root-cause synthesis (which requires understanding your design system well enough to know that six findings share one component), the effort estimates (which require knowing your codebase), and the owner assignments. You supply those; the model formats around them. This is the same division as everywhere in the program: the model does the high-volume transformation, you supply the understanding - here, the severity, the root causes, the effort, the ownership - that the model cannot. Use AI to make the report fast and consistent; do not let it invent severities it has no basis to assign, because a misjudged severity sends engineering to fix the wrong thing first.

Severity: The Field That Makes It a Plan

Of the five elements, severity deserves its own attention, because it is the one that converts a report from a list into a sequence, and getting it right is the difference between a report engineering follows and one they cherry-pick. Severity is a function of user impact and blast radius, not of how big the technical violation is. A focus indicator missing on the primary checkout button is critical, because it blocks keyboard users from completing a purchase, which is core functionality and high blast radius. A 3.9:1 contrast on a footer link is medium, because it is a real failure but low-traffic and non-blocking. The temptation is to rank by the size of the violation; resist it, and rank by what it does to users.

A useful severity rubric: critical means a user with a disability cannot complete a core task (blocked); high means significant difficulty or a core surface affected; medium means a real failure on a non-critical surface; low means a minor or rarely-encountered issue. Apply it consistently, and engineering can plan a remediation sprint that fixes the critical and high items first, which is the items that actually exclude users. A report where everything is "high" is as useless as a report with no severities, because it gives engineering no sequence; the discipline of honest severity is what makes the report actionable.

The Artifact: A Publishable A11y Findings Report

The named artifact is the publishable A11y Findings Report itself. It has a short executive summary at the top - how many findings, how many critical, the headline root causes, the rough total remediation effort - because the design lead or engineering manager who decides whether to fund the work reads the summary, not the forty rows. Then the findings table: each row a finding with its type, criterion, severity, owner, Figma frame, effort, and fix, grouped by severity and root cause. Then, ideally, a short "system fixes" section that calls out the handful of token or component changes that resolve the most findings, because those are the highest-leverage work and you want them impossible to miss.

Publishable means it can go straight into the engineering team's tracker, be read by a manager, and survive a stakeholder who wants to push back, because every finding is an objective fact with a criterion and the severities are defensible by user impact. This report is the capstone of the accessibility chapter not because it introduces a new audit, but because it is what makes all the previous audits matter: it is the bridge between finding accessibility problems and getting them fixed, and a designer who can build it is the designer whose accessibility work actually changes the product instead of decorating a Figma file with unactioned comments.

From One-Time Report to Living Governance Instrument

The report's value multiplies when it stops being a one-time artifact and becomes a living document. Give each finding a stable identifier and a status - open, in progress, fixed, won't-fix-with-rationale - update it each sprint as fixes land, and re-audit fixed items to confirm they are actually resolved. Now the report is not a snapshot but the backlog-of-record for accessibility, and it grows a trend: open criticals over time (which should march toward zero), findings closed per sprint, mean time to remediation by severity, and recurring root causes that signal where the design system is still letting failures through. Leadership can see, at a glance, whether accessibility is improving or sliding.

This matters especially for AI-generated products, which reintroduce focus, target, contrast, and alt-text failures with every generation, because the model's blind spots are persistent. Without a structured remediation pipeline, the team faces an unbounded stream of failures that per-instance fixing cannot outrun. The report's discipline - severity-prioritized, root-cause-synthesized, system-fix-surfacing - is exactly what makes the stream tractable: it routes recurring failures into structural prevention, the token and component fixes that kill whole classes of failure at once, and prioritizes the user-blocking ones. Tracked over sprints, the share of findings resolved by system fixes versus one-off patches becomes a real signal of whether the team is moving from endlessly catching failures to preventing them, which is the only sustainable posture for an AI-generated product.

Why the Report Is the Real Skill

It is easy to think the skill in accessibility is the auditing - knowing the ratios, operating the interface, spotting the failures. That is necessary, but it is not sufficient, and it is not where most accessibility work dies. Most accessibility work dies in the gap between finding the problem and getting it fixed, and that gap is closed by the report. The designer who can audit but cannot package the findings into an engineering-ready report has done work that does not ship. The designer who can do both is the one whose name is on the accessibility improvements that actually reached users.

This is also the skill that scales your influence. A report with severities, owners, root causes, and effort estimates is a document a design lead can take to an engineering manager and turn into a funded remediation sprint, a document that survives the move from your screen to the backlog to the sprint to the merged fix. It speaks engineering's language - tickets, severities, estimates, owners - which is what gets accessibility treated as work to be planned rather than a nice-to-have to be deferred. The report is where accessibility stops being the designer's private virtue and becomes the team's shipped commitment, and building it well is the difference between caring about accessibility and changing it.

It is also the skill that distinguishes a designer in the hiring market, because the binding constraint on shipped accessibility is the report, not the audit. Auditing competence is increasingly table stakes, supported by tools and common among accessibility-aware designers; the differentiating, hireable capability is turning findings into a report engineering executes and a manager funds - defensible impact-based severities, root-cause synthesis into system fixes, credible effort estimates, named owners, and an executive summary that wins the budget. A designer who can do that is the one whose accessibility work reaches users, and that is the capability worth building, naming in a portfolio, and being assessed on.

Putting It to Work This Week

Take the findings from your contrast, focus, target-size, alt-text, and motion audits and compile them into one report. Give every finding the five elements - finding-with-criterion, severity, owner, Figma frame, effort - plus a fix, ideally a system fix. Use AI to format and group, but assign the severities, root causes, effort, and owners yourself. Synthesize the findings into root causes so the forty symptoms become the dozen real fixes, and surface the system-level token and component changes that resolve the most at once. Write the executive summary for the manager who funds the work. Then publish it where engineering works, not in a Figma comment. The report is the deliverable that makes the whole chapter's auditing matter, and it is the artifact that turns your accessibility work from a private finding into a shipped fix.

Key Takeaways

• The audit is not the deliverable; the report is. Most accessibility work dies in the gap between finding a problem and getting it fixed, and that gap is closed by a report in the form engineering actually works with.
• Each finding carries five elements plus a fix: the finding as an observed fact with its WCAG criterion, a severity by user impact, an owner, a location as a Figma frame reference, and a remediation effort estimate - each element removing a reason the finding might be ignored.
• The report unifies the chapter's five audit types (contrast, focus, target size, alt-text, motion) into one normalized, triageable list with a type tag, and synthesizes the symptoms into root causes so forty findings become a dozen real fixes, several of them one-line system changes.
• Use AI to compile, format, and group the report - genuine drudgery it does well - but assign severities, root causes, effort estimates, and owners yourself, because those require knowing your users, design system, and codebase, which the model cannot.
• Severity is the field that makes the report a plan: rank by user impact and blast radius, not by the size of the violation, using a consistent rubric (critical blocks a core task, down to low for minor issues). A report where everything is high is as useless as one with no severities.
• The publishable A11y Findings Report - executive summary, normalized findings table grouped by severity and root cause, and a system-fixes section - is the capstone that makes all the chapter's audits matter, turning accessibility from a private finding into a shipped, funded commitment.