IRA and WCAG Findings: How to Structure Accessibility Results

ENGLISH VERSION

What is an accessibility finding and why does documenting it properly matter so much?

Think of it like going to the doctor. After running a series of tests, the doctor writes in your medical record: “patient doesn’t feel well.” No details. No test results, no data, no location of the problem. Would that record be useful for another professional who needs to treat you? Obviously not. Well, exactly the same thing happens with accessibility findings in an Accessibility Remediation Report (IRA).

An accessibility finding is each non-conformance, error, or area for improvement detected when evaluating a website or application against the WCAG 2.1 guidelines from the W3C. But the finding itself is worthless if it isn’t properly documented. An IRA with poorly structured findings is like a map without a legend: it technically exists, but it won’t get you anywhere.

Personally, I believe the quality of an IRA is directly measured by the quality of its findings. I’ve seen 200-page reports that were completely useless because the findings were vague, and I’ve seen 30-page reports that transformed an entire organization’s accessibility because each finding was clear, actionable, and well prioritized.

Anatomy of a Well-Structured IRA Finding

What elements should each finding include to be truly useful? After years of writing accessibility remediation reports, I’ve arrived at a structure that works consistently:

Does that seem like too much detail? Think of it like a recipe: if it just says “put stuff in the oven,” the result is unpredictable. If it says “preheat to 180°C, place the tray on the center rack for 25 minutes,” anyone can replicate the result successfully.

Classifying Findings by WCAG Levels

Not all findings carry the same weight. The WCAG 2.1 guidelines from the W3C establish three conformance levels, and your IRA should reflect this hierarchy:

Level A: The Absolute Basics

Level A criteria represent the bare minimum. If your website doesn’t meet these criteria, you’re actively excluding people with disabilities. According to data from WebAIM’s annual WebAIM Million report from 2025, 95.9% of home pages analyzed had at least one automatically detectable Level A error. Tools like axe DevTools from Deque Systems can identify many of these problems instantly.

Typical examples: images without alt text (1.1.1), videos without captions (1.2.2), forms without labels (1.3.1), content not navigable by keyboard (2.1.1).

Level AA: The Reference Standard

Level AA is what most legislation requires, including the European Accessibility Directive and the European Accessibility Act. When we talk about “meeting WCAG,” we almost always mean Level AA. Your IRA should pay special attention to these criteria because they determine legal compliance.

Examples: insufficient color contrast (1.4.3), non-resizable text (1.4.4), inconsistent navigation (3.2.3), error messages without suggestions (3.3.3).

Level AAA: Excellence

Level AAA is rarely required by law, but including it in your IRA demonstrates real commitment to accessibility. Personally, I recommend documenting AAA improvement opportunities as “enhancement findings,” distinguishing them from mandatory non-conformances.

Tools for Detecting and Documenting Findings

What tools can you use to identify findings for your IRA? The reality is that you need to combine automated and manual evaluation:

According to Deque Systems, automated tools like axe DevTools can detect between 30% and 57% of accessibility issues. The rest requires expert manual evaluation. Your IRA should clearly indicate which methodology was used for each finding.

Finding Prioritization: The Key to an Actionable IRA

What’s the point of having 150 documented findings if the development team doesn’t know where to start? Prioritization is what turns an IRA from a passive document into an active roadmap.

The matrix I use and recommend crosses two variables:

• User impact: How much does this problem affect the experience of people with disabilities?
• Remediation effort: How much time and resources are needed to fix it?

This cross gives you four clear quadrants:

Personally, I always advise starting with quick wins. Nothing motivates a team more than seeing fast results. A finding like “button without an accessible label” can be fixed in five minutes and improve the experience of thousands of users.

Common Mistakes When Documenting IRA Findings

Want to know what separates a mediocre IRA from an excellent one? These are the mistakes I see most frequently:

• Generic findings: writing “contrast issues” without specifying where, which elements, or what contrast ratio was found.
• Lack of evidence: not including screenshots, code snippets, or results from tools like axe DevTools or WAVE.
• No user impact: describing the technical problem without explaining how it affects real people.
• Not indicating remediation: pointing out the error without proposing a concrete solution. A good IRA is also a solution guide.
• Mixing severities: treating all findings with the same urgency, which paralyzes the development team.
• Ignoring positive findings: a complete IRA also documents what works well, not just the errors.

IRA Template: Recommended Structure for Findings

If you’re creating your first IRA or want to improve your current template, here’s the structure I recommend based on the W3C’s WCAG-EM methodology:

• 1. Executive summary: overall view of the accessibility status with key metrics.
• 2. Evaluation scope: pages evaluated, technologies, tools used.
• 3. Methodology: combination of automated testing (axe DevTools, WAVE) and manual testing.
• 4. Findings summary: summary table with count by severity and WCAG criterion.
• 5. Detailed findings: each finding with the 9-element structure described above.
• 6. Positive findings: elements that already comply with WCAG 2.1.
• 7. Remediation roadmap: prioritization and correction schedule.
• 8. Appendices: screenshots, tool results, WCAG references.