This workbook functions as the primary data and analysis export for the accessibility framework. It compiles processed findings, deduplicated clusters, prioritized fix sequences, and database-ready data schemas into a single offline file.
The workbook is organized into three distinct structural layers depending on your immediate goal:
| Field family | Meaning / Data Schema Purpose |
|---|---|
| Rule | Clear, human-readable display title for the issue. |
| Rule Id | The original, technical identifier used by the source scanner tool. |
| WCAG | The specific compliance success criterion code (e.g., 1.4.3). |
| WCAG Name | The official title of the criterion (e.g., Contrast (Minimum)). |
| Severity | Normalized severity scales used for predictable sorting and triage. |
| Consensus | An overlap signal indicating how many tools matched on a bug pattern. |
| Engine Family | A normalized family label such as Axe, HTMLCS, IBM, Alfa, Validator, Browser, Keyboard, Visual, or AT. This helps distinguish repeated findings from the same underlying engine from findings supported by truly independent tool families. |
| Confidence | A broader evidence strength judgment score. |
| Issue Rank Score | Calculated numeric prioritization value used to sort the backlog. |
| Pattern / Display Pattern | A shared identifier and human label for a repeated issue family. |
The executive overview sheet tracking macro KPIs like total Violations, Pages Affected, Design System Impact, Accessibility Debt Index, and Accessibility Opportunity Score.
One of the most vital analyst tabs. It processes raw, high-volume findings down into manageable, repeated issue families. Typical schemas map out Rule properties, WCAG details, severity levels, owner teams, inferred root causes, and original engine sources.
🎯 Best used for: Identifying which specific code bugs repeat across the digital estate, evaluating which look systemic, and deciding which clusters to triage first.
The granular analyst log: renders one distinct row per processed finding, enriched with readable fields like Page URLs, DOM structural context, tool messages, engine origins, engine-family labels, and adapter-specific context such as Alfa thresholds or Nu HTML Checker line/column locations. The workbook strictly enforces an architecture where bare WCAG codes are never mixed into human-readable Rule labels.
Flattered analytical tables tracking stable keys, ownership domains, and page spread metrics designed specifically for downstream BI ingestion and custom modeling.
A normalized star-schema database model mapping facts and dimensional sheets (Page, Rule, Component, Pattern) to power advanced relational reporting.
A pre-ranked remediation shortlist tracking pattern names, component roots, affected URL counts, responsible developer teams, and priority scores.
💡 Priority score note: The numeric score acts purely as a ranking aid. Multiple top rows can easily tie if they share identical technical severity values and page spread footprints.
A highly simplified, root-cause summary layout optimized for clean, concise management-style reporting.
Some tools emit rows that are not hard compliance failures but still matter operationally. Depending on your active adapter configurations, these appear labeled as incomplete, potentialviolation, warning, or Alfa cantTell outcomes. Nu HTML Checker warnings are also preserved as markup/ARIA validity evidence. The analyzer intentionally preserves these rows for deep structural exploration, but they should not be calculated as confirmed failures in your core compliance reporting.
The workbook and dashboard share a core engine and will usually align perfectly. However, because dashboards summarize data, the workbook is the superior space to inspect micro-level field attributes. If a metric looks unexpected on the frontend, cross-reference it against Issue Details, Dim Rule, and Systemic Clusters.