The **Accessibility Systemic Analyzer** serves as an advanced architectural analysis and reporting layer for multi-tool accessibility scan outputs. It is designed explicitly for development and product teams managing large digital estates where issue backlogs have grown too massive to sensibly triage page by page[cite: 10].
Instead of logging every single automated scanner match as an isolated, independent defect, the engine normalizes incoming source attributes, deduplicates overlapping data rows, maps entries to standard WCAG taxonomies, and groups matching issue footprints into highly actionable remediation patterns. This pipeline generates an interactive visual dashboard alongside a detailed spreadsheet workbook built for rapid remediation planning.
Automated testing engines record entries per URL node. While this method is excellent for localized debugging, it makes high-level remediation orchestration incredibly difficult. A single global component bug will trigger hundreds of repetitive failures across a site's templates.
| Scanned Page Location | Automated Scanner Output Item |
|---|---|
| Home | Button contrast failure |
| Product page | Button contrast failure |
| Cart | Button contrast failure |
| Checkout | Button contrast failure |
Standard reporting structures force teams to triage these as four distinct, unrelated tasks.
💡 **The Reality:** The actual engineering root cause is simply **one single shared component** possessing a faulty CSS color assignment.
The analyzer exists to collapse high-volume raw rows into a lean list of high-impact reusable remediation targets.
To clean and structure high-volume testing data, the analyzer executes the following pipeline functions[cite: 10]:
| Testing Engine Source | Capability & Parsing Attributes |
|---|---|
| axe-core | Extracts WCAG structural metadata; preserves verified violations and manual-review check rows. |
| axe-scan | Ingests axe-derived scanner files; manages partial/incomplete contrast logs. |
| IBM Accessibility Checker | Maps native IBM rule identifiers directly to WCAG; models distinct violation and
potentialviolation parameters.
|
| Lighthouse | Parses automated accessibility failure audits and pulls out WCAG tags from underlying debug arrays[cite: 10]. |
| Oobee | Crawler-oriented architecture optimized to sweep across massive digital estates and page inventories. |
| UUV | Run/flow-oriented tracking system incorporating strict severity normalization and compliance metadata parsing. |
| Pa11y | Modeled as a unified source pipeline while cleanly tracking individual runner properties (e.g.,
axe vs htmlcs).
|
| HTMLCS / html-sniffer | Enables HTMLCS-specific parsing schemas matching technique-style rule titles. |
Certain adapters intentionally preserve "needs-review" flags rather than deleting them. This behavior ensures engineering teams can investigate subtle potential flaws.
The analyzer runs dedicated rule-to-compliance mapping frameworks, leverages fallback messages, and enriches criteria metadata. To maximize text scannability, the database architecture completely separates rule vocabulary layers:
Contrast (Minimum)).
1.4.3).
Pa11y records are no longer tracked as two synthetic tools when axe and HTMLCS outputs inhabit the same
file. The engine tracks a single, clean pa11y pipeline while maintaining precise
per-issue runner metadata.
Label rendering has been significantly sharpened. The engine avoids raw tool codes if a clear,
humanized title can be derived using metadata mappings or technique-aware context flags (e.g.,
1.4.6 [G17]).
Analytical dashboard elements and spreadsheet summary tabs accept only real, verified WCAG codes. Raw engine error descriptions and unmapped technical strings are blocked from entering compliance graphics[cite: 10].
The primary analytics drilldown interface features real-time keyword text filtering, custom row display limits, and full pagination.
A **systemic issue** is any finding pattern that repeats frequently enough that a single development change will repair multiple page variants simultaneously. The analyzer relies on three distinct operational classifications to separate these concerns:
The application engine outputs a static-build track built for quick, documentation-style hosting
platforms. This build outputs analytical dashboard charts, support matrices, page coverage checks, and
fully searchable drilldowns alongside a downloadable spreadsheet workbook model. The data model
features built-in fields like tool_count, consensus, and confidence to
help your engineering team track exactly how much tool agreement backs an issue.
Subjective evaluation criteria—such as image alt-text context quality, meaningful button labels, logical keyboard focus tracking, error recovery text clarity, document layout semantic clarity, and cognitive accessibility paths—must still be validated through human inspection.
python -m venv venv
source venv/bin/activate
pip install -r requirements.txt
uvicorn app.main:app --reload