The Accessibility Systemic Analyzer is evolving from a multi-tool reporting platform into an accessibility intelligence engine.
Rather than simply aggregating reports, the project is focused on turning accessibility evidence into actionable insight.
Don't count findings. Find consensus.
Collects, normalises, compares, and visualises accessibility evidence from multiple engines.
Moves from individual findings towards components, confidence, repeated patterns, and root causes.
Explores suggested repairs, trends, design-system insights, and prioritised remediation guidance.
Phase 1 focuses on gathering accessibility evidence from multiple independent sources and presenting it in a unified, meaningful way.
Instead of manually comparing reports from numerous accessibility tools, the analyzer normalises findings, removes duplication where possible, and highlights where tools independently agree.
Phase 1 asks: What did the tools find, and where do they agree?
| Tool / view | Purpose |
|---|---|
| axe-core | Automated WCAG testing and widely used accessibility rule coverage. |
| axe-scan | Axe-derived reporting through an additional scan pathway. |
| IBM Accessibility Checker | Confirmed, potential, and advisory accessibility findings. |
| Speca11y | Automated WCAG testing including some draft WCAG 3.0 rules. |
| HTML CodeSniffer / HTMLCS | WCAG technique-style rule evidence and review-oriented findings. |
| Lighthouse | Browser-based accessibility audit metadata and failures. |
| Oobee | Crawl-style accessibility evidence and axe-family results. |
| UUV | Flow-based and heuristic accessibility evidence. |
| Alfa | ACT-style outcomes including failed and needs-review results. |
| Nu HTML Checker | Markup, validation, and standards-level evidence. |
| Pa11y Axe / Pa11y HTMLCS | Additional axe and HTMLCS evidence through Pa11y runners. |
| Visual Explorer | Clean page previews and keyboard tab-order maps from the same capture flow. |
| Virtual Screen Reader | Structured reading-order and semantic output. |
| Contrast Checker | Visual contrast evidence and colour-pair analysis. |
The analyzer is continually tested against a growing benchmark suite representing different kinds of real-world accessibility evidence.
| Benchmark type | Why it matters |
|---|---|
| Government / reference-quality sites | Useful baseline where stronger accessibility implementation is expected. |
| Retail / ecommerce | Tests product pages, navigation, imagery, forms, and transactional patterns. |
| Modern SPA / Next.js | Exercises component-heavy, JavaScript-rendered, creative and animation-rich websites. |
| Legacy / malformed HTML | Tests old markup patterns, validation failures, frames, and structural oddities. |
| Deliberately poor UX | Useful for hostile interaction design, keyboard problems, confusing forms, and regression testing. |
| Authenticated flows | Validates login, storage state, protected-page analysis, and real application journeys. |
Phase 2 shifts the focus away from individual findings and towards understanding accessibility at a higher level.
Instead of answering:
How many issues were found?
the analyzer will begin answering:
What needs fixing?
Findings will be associated with likely interface components rather than grouped only by page or WCAG rule.
The goal is to identify repeated design-system issues rather than isolated page defects.
Many accessibility reports contain hundreds of repeated findings. Phase 2 aims to identify the underlying repair.
| Instead of | The analyzer identifies |
|---|---|
| 63 button findings | A shared Button component pattern. |
| 41 contrast failures | A shared colour token or visual treatment. |
| 82 missing label findings | A repeated Form component issue. |
| Many image-alt issues | A repeated Image or Gallery component problem. |
Not every accessibility finding carries the same weight. Future scoring can consider:
Future visualisations may include:
These visual layers build naturally on the current Visual Explorer, Tab Map, Virtual Screen Reader, and Contrast Checker outputs.
Phase 3 is intentionally more exploratory. The broad idea is to help teams move from understanding evidence to planning repairs.
Potential ideas include:
Accessibility tools already identify problems. The Accessibility Systemic Analyzer is focused on understanding those problems.
Ultimately the goal is to help answer questions such as:
From findings to evidence. From evidence to consensus. From consensus to meaningful repairs.