Understanding Axe-Core Iterative Testing

Overview

When you run accessibility tests in CodeFrog and fix the reported issues, you may notice that re-running the test reveals new issues that were not in the previous report. This is expected behavior, not a bug. Axe-core, the accessibility testing engine used by CodeFrog, works iteratively by design.

Why Results Change After Fixes

Axe-core has rule dependencies — some checks are only evaluated when prerequisite conditions are met. When you fix one issue, it can unlock additional checks that were previously skipped:

• Missing landmark fixed → Child elements within the landmark are now checked for proper ARIA attributes and roles
• Contrast issue on a container fixed → Child elements that inherit the container’s styling are now individually evaluated for contrast compliance
• ARIA role added → Additional ARIA attribute validation rules are triggered (e.g., required aria- properties for that role)
• Structural fix applied → DOM changes cause new elements to become testable that were previously hidden or inaccessible to the scanner

This is similar to how a code compiler might show one error that, once fixed, reveals five more errors that were previously masked.

The Iterative Workflow

The recommended approach for accessibility testing is:

1. Run the accessibility test in CodeFrog (standalone or via Mega Report)
2. Fix the top-priority issues — focus on critical and serious violations first
3. Re-run the test to check your fixes and discover any newly exposed issues
4. Repeat until the report comes back clean

Each cycle typically reveals fewer new issues than the previous one. After a few rounds, you should reach a clean report where all automatically detectable issues have been resolved.

What This Means for Your Score

• A clean report (grade A) means all issues that axe-core can automatically detect have been resolved
• A report showing new issues after fixes does not mean your previous fixes were ineffective — it means the engine can now check deeper
• The total number of issues may temporarily increase after a fix before trending back down

Tips for Efficient Testing

1. Fix critical/serious issues first — these have the highest impact and are most likely to unlock dependent checks
2. Batch your fixes — fix all reported issues before re-running, rather than fixing one at a time
3. Use Mega Report sitemap mode — test all pages at once to catch site-wide patterns
4. Remember automated limits — axe-core catches approximately 57% of WCAG issues in controlled audits (per Deque’s research), though real-world detection rates for automated tools are typically 20–30% due to page complexity and dynamic content. Manual testing with assistive technologies (screen readers, keyboard navigation) is still required for full WCAG conformance

Related Topics

• Accessibility Testing — Full guide to accessibility testing in CodeFrog
• WCAG Levels Explained — Understanding WCAG A, AA, and AAA conformance levels
• Mega Report — Run accessibility alongside 18 other tests in one report
• Accessibility Best Practices — Tips for building accessible websites