Statamic A11Y Report Laravel Package

Product Decisions This Supports

• Accessibility compliance posture as a tracked product metric, not a one-off audit. Because scans are persisted and comparable ("against the last scan"), a PM can treat WCAG-adjacent findings as a trendline across releases rather than a point-in-time vendor report. That turns "are we accessible?" into "did this sprint regress us, and by how much?"
• Release gating and regression ownership. The CLI command (php please a11y:report) is scriptable, so it can sit in a pre-deploy checklist or CI job alongside tests. A PM can decide, per release train, whether a rising open-issue count blocks a launch or merely files a ticket — and have the artifact to defend either choice.
• Multisite governance and scoping decisions. The ['*'] scope semantics ("every site" vs "this site") map directly to an org question: does each brand/site own its accessibility budget, or is it a platform-level commitment? The 1.2.2 scoping fix makes per-site attribution trustworthy enough to use in a per-site scorecard or stakeholder report — previously a single-site install could report "no completed scan" next to live issue counts, which is exactly the kind of contradiction that destroys trust in a dashboard.
• Build vs. buy for accessibility tooling. This is a thin, self-hosted layer over an existing scanning engine, aimed at Statamic's control panel. If the org already pays for Siteimprove, axe Monitor, or Pope Tech, this package's value is proximity (same CP, same content model, same site scoping), not scanning depth. Choose it to close the "nobody looks at the external dashboard" gap; choose an external vendor when you need legal-grade VPAT/audit artifacts and manual-review workflows.
• Editorial and content-ops decisions. Reading-level bands (now consistently "Grade 9–10") and open-issue counts per page let content owners prioritize rewrite work. A PM can set a plain-language target for a content type and measure it without leaving the CMS.
• Roadmap trade-off: invest in content remediation vs. template/systemic fixes. Persisted per-scan issue data lets you tell whether the same defects recur across pages (systemic — fix the template) or are scattered (content — fix the workflow).

When to Consider This Package

Adopt when:

• The product runs on Statamic and the team wants accessibility signals in the control panel rather than a separate SaaS login that goes unchecked.
• You have (or are heading toward) a compliance obligation — public-sector procurement, the European Accessibility Act, ADA-adjacent risk, or enterprise customer questionnaires — and need recurring evidence rather than a single audit PDF.
• You run multisite and need per-site accountability with a defensible "all sites" rollup. Post-1.2.2 the site-attribution logic is shared across the command, the CP button, and the worksheet, which is the minimum bar for using these numbers in a report someone might forward to a client.
• You want a cheap, low-ceremony regression check wired into deploys, and you accept automated scanning as a floor, not a ceiling.

Look elsewhere when:

• You need manual audit coverage, assistive-technology testing, or certified conformance statements. Automated scanners catch a minority of WCAG failures; this package cannot produce a VPAT.
• You are not on Statamic. The value is the CP integration; porting the idea is cheaper than adopting the package.
• You need enterprise workflow: issue assignment, SLA tracking, ticketing integrations, historical retention guarantees, per-rule suppression with audit trails. This is a CMS addon, not a compliance platform.
• Operational discipline is thin. v1.2.2 requires running php please a11y:report:install after composer update to backfill site names on existing scans. Teams that can't reliably execute a documented post-upgrade step will end up with discontinuous trendlines and mismatched "against the last scan" comparisons — the exact confusion this release fixes.
• The package's roadmap and maintenance aren't visible enough for your risk appetite; it's a small addon, so bus-factor and version cadence should be checked before it becomes an audit dependency.

How to Pitch It (Stakeholders)

For executives: Accessibility is now a procurement gate and, in some markets, a legal one. This addon puts a recurring, low-cost accessibility signal inside the tool editors already use, so problems surface before a customer or auditor finds them. Cost is a Composer dependency and a small amount of deploy-pipeline wiring — not a new SaaS contract or a consulting engagement. It does not replace a formal audit; it makes sure we know where we stand every week instead of every other year.

For engineering leadership: It's a thin, well-behaved Laravel/Statamic addon — a console command, a dashboard widget, a config file published via vendor:publish --tag=statamic-a11y-report-config, and persisted scan records. v1.2.2 is a pure bugfix release with no breaking changes, but it does require running the package's install command after composer update to backfill site attribution. That's a one-line addition to the upgrade runbook, not a migration on our schema. Two things in this release are worth noting as quality signals: the scoping bug was caught by installing the previous version into a fresh site and following the README literally (Statamic's Marketplace Rule 06 check), and the fix addresses a real trust failure — a widget reporting "no completed scan" while displaying issue counts from that scan. The command, the CP button, and the worksheet now share one lookup, which also closes a multisite path where a report could carry another site's name. If we adopt, I'd ask for one thing before it becomes load-bearing: pin the version, run the report in CI on a non-blocking basis for a sprint, and confirm the numbers track with reality before we put them in front of a customer.