You've been through the three layers of evaluation: automated (06-02), manual (06-01), and with real users (06-03). The result is a heap of heterogeneous findings: axe violations, notes from your manual checklist, quotes from Marta, times from Lucía. Now comes the part that separates a useful audit from a PDF nobody reads: interpreting those results and acting on them with judgement. A report with 200 unprioritized findings paralyzes; one with 6 well-weighted findings turned into tasks moves the product. In this lesson you'll learn to read a report, understand severity and impact, prioritize, discard false positives, and close the loop so the problems don't come back.

1. Anatomy of a finding
2. Severity versus user impact
3. Prioritizing: not everything is urgent
4. VPAT / ACR: the conformance report
5. Discarding false positives
6. From finding to remediation task with a "Definition of Done"
7. Cursalia audit report (example)
8. Preventing regressions: accessibility in the Definition of Done

A well-documented finding—whether it comes from a tool or a user session—always has these fields. If a report doesn't include them, demand them: without them you can't act.

The source field matters more than it seems: a finding that appears in axe and in a user session is unquestionable; one that only came out of a tool may be a false positive (section 5).

Be careful not to confuse two things:

• Technical severity (the one the tool assigns): axe says "critical/serious/moderate/minor" according to its rule catalog. It's generic; it doesn't know your product.
• User impact: how much real harm it causes in your context. It depends on whether it blocks a task and on how many people it affects.

A simple model for classifying impact:

The key: a fault axe marks as "moderate" can be blocking in your product if it lands on the enrollment button, and a "critical" one from axe can be minor if it's on a page nobody visits. The tool's severity is the starting point, not the verdict.

Prioritizing means weighing impact × reach. Two axes:

• Severity for whoever suffers it: blocking, serious, or minor? (section 2).
• Reach: on how many pages does it appear, and how heavily are they used? A fault on the course page and the catalog (Cursalia's most visited pages) affects almost every user; the same fault on the "Legal notice" page affects very few.

Practical rule: blocking issues on heavily used pages first; leave the minor issues on marginal pages for last. And if something is trivial to fix (5 minutes) even though it's minor, do it now: it's free.

When an organization (or a client about to buy Cursalia) wants to know "officially" how accessible it is, a standard document is used:

• VPAT (Voluntary Product Accessibility Template): the template, published by ITI. It's the blank format.
• ACR (Accessibility Conformance Report): the VPAT already filled in for your product—the resulting report.

It goes criterion by criterion (WCAG, and sometimes the European EN 301 549 standard or the US Section 508) and marks each one with a level of support:

What it's for: it's the document a buyer (a university, a company) asks for before signing a contract for an e-learning platform. An honest ACR—one that acknowledges its "Partially Supports"—builds more trust than one that swears "Supports" across the board. Don't confuse it with the internal audit report (sections 1-3): the ACR faces third parties; the audit is your to-do list.

Before creating tasks, filter out the noise (we saw this in 06-02):

• Reproduce the finding by hand: if axe flags "low contrast" on text that turns out to be hidden or over a decorative image, it's not a real problem.
• Check the context: an aria-* marked as invalid may be correct for your specific pattern.
• Cross-reference sources: if something appears in the tool but neither you by hand nor the users notice it, be suspicious. If it appears in several sources, it's solid.

Document why you discard each false positive. A finding silenced without justification becomes, months later, "why did we ignore this?".

A finding isn't actionable until it's a task with a verifiable Definition of Done. Compare:

• Bad (not actionable): "Improve the catalog's accessibility".
• Good (actionable): "Give the favorite button (button.fav-btn) an accessible name. Done when: NVDA announces 'Add to favorites, button' and axe no longer reports button-name."

The Definition of Done must state how it's verified and with what test (automated, manual, or user), closing the loop with the three previous lessons.

Combined audit of Cursalia (axe + manual checklist from 06-01 + user session from 06-03). Prioritized findings:

Remediation plan, each finding mapped to the course lesson where the solution lives:

Notice two things: the three most serious findings (P1) came from users and manual testing, not from the tool—exactly the module's message. And each task points back to where you already learned to fix it: evaluation closes the loop with construction.

Fixing the 6 findings is worthless if they come back two sprints later. To keep them from regressing, accessibility enters the team's Definition of Done: a story isn't "finished" until it meets accessibility criteria. Example DoD checklist for Cursalia:

This closes the loop of the whole of Module 6: automated to avoid regressing, manual for judgement, users for usability, and the report to prioritize and verify. Accessibility stops being a one-off audit and becomes part of the process.

• Treating the tool's severity as absolute truth: weight it by real impact and reach in your product.
• Prioritizing by "what's easy" instead of by impact: fixing 20 minor things while a blocking issue stays alive is bad management (unless the minor one is trivial: then, yes, knock it out).
• Confusing the ACR with the internal audit: the ACR is for third parties; the audit is your backlog. Don't mix them.
• Closing tasks with no Definition of Done: "I had a look" isn't done. Define how it's verified and with what test.
• Not documenting false positives: they get reopened endlessly.
• Fixing and not hardening: without accessibility in the Definition of Done, everything comes back.
• Tip: in the report, sort by priority and put the user impact in human language ("Marta doesn't know whether she's enrolled"), not just the WCAG code. It's more persuasive and prioritizes better.

Exercise 1. axe marks as "critical" a missing alt on a decorative footer icon (appears on every page) and as "serious" that the successful-enrollment message isn't announced (only in the purchase flow). By your impact criteria, which do you prioritize, and why is the tool's severity misleading here?

Exercise 2. A university client asks for "the Cursalia VPAT" before signing. Explain what exactly you hand over (VPAT vs ACR), what conformance states each criterion can have, and why it's wise to be honest about the "Partially Supports".

Exercise 3. Turn this finding into an actionable task with a Definition of Done: "Insufficient price contrast (4.35:1) on the course page, WCAG 1.4.3 AA, detected by Pa11y." Also state which test you'd use to verify the fix.

Solution 1. You prioritize the unannounced enrollment message, even though axe marks it "serious" and the alt "critical". Reason: the unannounced message is blocking—Marta can't confirm whether she enrolled, in the purchase flow, which is essential and heavily used—whereas the alt on a decorative icon is minor (a reader ignores it with no loss of information) no matter that it appears on every page. The tool's severity is generic and doesn't know which task each fault blocks in your product; you have to reinterpret it by real impact and reach.

Solution 2. You hand over an ACR: the VPAT (ITI's template) already filled in for Cursalia. It goes through each WCAG criterion (and possibly EN 301 549 / Section 508), marking it as Supports, Partially Supports, Does Not Support, or Not Applicable. It's wise to be honest about the "Partially Supports" because a realistic ACR builds trust and avoids liability for false claims; swearing "Supports" across the board and then having the client hit barriers destroys credibility and can carry contractual/legal consequences.

Solution 3. Task: "Adjust the price color on the course page to reach a contrast ratio ≥ 4.5:1 against its background (WCAG 1.4.3 AA)." Definition of Done: the DevTools contrast eyedropper shows ✓ AA for that text and Pa11y/axe no longer report the contrast error on #price-course. Verification: an automated test (Pa11y/axe in CI) plus a quick manual check with the color picker from 06-01. (The how of adjusting the color is in Module 4, lesson 04-04.)

With this lesson you close Module 6: you now know not just how to build accessible interfaces, but how to verify that they are and act on the results. You've mastered the full cycle—automated, manual, users, and report—on "normal" pages: a course page, a catalog, an enrollment form. But the real web is harder than that. What happens when content changes without a reload and has to be announced (Marta's P1 finding points right there)? When the whole application is a SPA and navigation doesn't reload the page? When Cursalia is translated into several languages and you have to manage lang, text direction, and localization? And where is the standard heading with WCAG 3.0? All of that—complex interactions and dynamic content, accessibility in SPAs, internationalization/localization, and future trends—is Module 7, where we take what we've learned into advanced territory.