bpmore/statamic-a11y-docs
A Statamic addon that brings accessibility documentation into your control panel, giving editors and developers quick reference guidance for creating and maintaining accessible content while building and managing your site.
This is a Statamic addon, so start where Statamic developers always start: composer require it, then look for the nav item in the control panel. Since 1.3.2 the nav item and the dashboard share the same title, Document checks — that's your landing page and the name to search for in the codebase when you need to trace a route or a permission.
Minimal path:
The first real use case is a library audit: run the checks, filter the queue to critical findings, and triage. If you have hundreds of untagged PDFs you will not work the queue unfiltered — filters are the primary navigation, pagination is the fallback.
If the free Site Weather addon is already installed, you get a Documents band on its tile for free. That's the recommended first integration: it turns the dashboard's numbers into a single glanceable severity, which is often all a content team actually needs day to day.
Schedule the check, don't click the check. Wire the addon's check into routes/console.php or your scheduler so results are always fresh. A dashboard showing last month's scan is worse than no dashboard, because people trust it.
Treat the remediation queue URL as state. Filters survive pagination, which means a filtered queue is a shareable link. Use that: file a ticket as "queue filtered to type=pdf&severity=critical" rather than "go to Document checks and click around". Deep links into filtered views are the cheapest workflow improvement available here.
Use the Site Weather band as a monitor, not a gate. The band is a coarse five-step scale — clear, fair, overcast, rain, storm — with storm triggering at a tenth of the library having critical problems. That's a fine signal for "does someone need to look at this today" and a bad signal for "is this release blocked". If you need a release gate, read the underlying finding counts directly and enforce your own threshold.
Calibrate against your own SLA. The 10%-critical-storm threshold is the addon's opinion. If your library is 90% legacy scans, you will live in permanent storm and the band stops meaning anything — either accept that and read the counts, or adjust what you classify as critical in config so the band tracks something actionable.
Separate the audience from the operator. Editors need the remediation queue and the "what's wrong with this file" view. Whoever owns the check configuration, scheduling and thresholds needs the dashboard and settings. Map these to Statamic permissions early rather than granting the whole addon to everyone.
Re-run after deploy, deliberately. Upgrading re-checks nothing by design, so any results you see immediately after composer update are pre-upgrade results rendered by post-upgrade code. Trigger a run as an explicit deploy step if the dashboard is load-bearing.
"Unknown" is not "clear", and you must not render it as such. A Site Weather band reads unknown when the addon is installed but never configured, or when nothing has been checked yet. If you're piping this into your own status page, uptime check, or Slack digest, handle unknown as its own state. Collapsing it into green is the one way this integration can actively mislead — the band's whole design is built around refusing to say "clear" when nothing has failed only because nothing has run.
The Site Weather band is silently optional. Site Weather is suggested, not required. Without it nothing changes — no errors, no placeholder, just no band. Don't write documentation or onboarding that assumes it's there, and don't let a support ticket about "the weather tile is missing" turn into an hour of debugging an addon that was never installed. Check composer show first.
Watch page two. Fifty per page was always the limit; before this release the screen simply drew no way past it. If you have a library with 890 untagged PDFs, that means pagination now exposes a much larger queue than anyone could previously reach in the UI. Two consequences: users will discover findings they didn't know existed (expect a spike in "new" issues that aren't new), and you should check that any bulk action or export handles the full result set rather than the first fifty.
Re-publish views if you've overridden them. The header rows, the visible filter labels and the retitled dashboard are almost certainly view changes. Any published copy of those Blade templates in your app will shadow the new versions and quietly keep the old unlabelled tables — which is a particularly bad outcome for a package whose entire purpose is reporting accessibility problems. Diff your published views against the package's after upgrading.
Layout regressions from visible filter labels. Adding labels to filters changes vertical rhythm on the queue screen. If you have custom CSS or a control-panel theme, spot-check the queue at a couple of widths before you call the upgrade done.
Assertions on titles will break. The dashboard is now titled "Document checks", matching the nav item. If you have feature tests or smoke tests asserting a different page title or heading, expect a red build — it's a test fix, not a regression.
Automated checks are not a compliance certificate. The accessibility improvements in this release are welcome, and the addon now practises more of what it reports. But a clean dashboard means "no findings from these rules", and no rule engine catches every WCAG failure. Present the output as triage input, not sign-off.
Upgrade safety. Nothing in this release is breaking: no renamed public API, no config key removals, no deprecations. It's additive — an optional integration, pagination, and accessibility fixes. Upgrading is safe, and the only action item is triggering a re-check if you want fresh results.
How can I help you explore Laravel packages today?