Statamic A11Y Gate Laravel Package

Product Decisions This Supports

Feature and roadmap decisions around content accessibility. This addon enforces accessibility at the point of publish rather than at audit time. That shifts the roadmap conversation from "when do we commission an accessibility audit?" to "which checks do we gate on, and which do we surface as warnings?" Useful when scoping work on authoring UX, editorial workflows, or a public-sector/EAA-adjacent compliance commitment.

Build vs. buy for the governance layer. A PM can treat this as the cheap option: it plugs into Statamic's existing save pipeline (the release notes show it hooks the same reveal/scroll behaviour Statamic's own save pipeline uses) and adds a control panel plus a findings list. The alternative — bespoke validation, custom fieldtypes, or a manual pre-publish checklist — is weeks of work for the same outcome. Buy, and spend the engineering budget on remediation instead.

Prioritising remediation work from real findings. Every finding names the specific page element to fix (a duplicate heading's text, an image's src, a link's words). That gives a PM a concrete, itemised backlog of content debt — good input for sprint planning and for deciding whether to fix content, templates, or both.

Scope-setting with stakeholders who want "compliant". The maintainer deliberately refuses to claim completeness, and this release doubled down on that (the Tools page line changed from "Anything that would fail WCAG 2.2 AA stops the publish" to "Anything it finds"). For a PM this is a feature, not a gap: it prevents the addon from becoming a false compliance shield. Use it to frame accessibility as a process with a tool that catches a subset, and budget separately for manual audit and colour-contrast review, which this does not check.

Deciding whether to make it mandatory. Because it can block saves, adoption is a policy decision, not just a technical one. The v0.10.2 fix that sends authors to the tab where the refusal is drawn (previously a toast in the corner on tablets and small laptops, with the detail on a tab they weren't looking at) is exactly the kind of thing that determines whether authors tolerate a hard gate. Roll out to a pilot group before making it org-wide.

Security posture for authoring roles. The XSS fixed here is stored: anyone who could put a heading on a gated entry could plant a payload that executed in an admin's control panel when they pressed Check or had a save refused. If your authoring base includes lower-trust roles — freelancers, contributors, multi-tenant editors — this is a real internal-threat vector and should inform role design and the upgrade timeline.

When to Consider This Package

Adopt when:

• You are on Statamic (the README floors reference statamic/statamic 6.5) and content authors publish through the control panel. There is no equivalent story for WordPress, Craft, or a headless-only setup.
• Accessibility is a stated commitment — public sector, procurement requirements, EAA-adjacent obligations, or an internal design-system standard — and you want a control at the publish step rather than only after the fact.
• You have repeatable content patterns (headings, images, links) authored by people who are not accessibility specialists, and you want structural issues caught at the source.
• You want a cheap, incremental governance layer on top of existing Statamic installs, and can absorb a pre-1.0 dependency.

Look elsewhere, or supplement heavily, when:

• You need WCAG conformance evidence. This addon explicitly does not check colour contrast and explicitly refuses to claim it stops everything that would fail 2.2 AA. Anything with a legal or audit dimension needs a manual audit programme alongside it.
• You need vendor SLAs or paid support. Support is a single public issue tracker, answered by one person, with no response-time promise. That is fine for an internal tool and unacceptable where an accessibility gate is a contractual obligation.
• You cannot accept pre-1.0 API churn. At 0.10.x, breaking changes are expected; pin the version and budget for upgrade work each release.
• Your authors are hostile to hard blocks and you can't run a pilot. A publish gate that misfires (or that authors can't see, as in the bug fixed here) gets bypassed or disabled.
• You need the package to check rendered output in the browser — this is largely server-side findings on saved content.

Immediate action item regardless: 0.10.1 and earlier are affected by the stored XSS. Upgrade, and add php artisan vendor:publish --tag=statamic-a11y-gate --force (or php artisan statamic:install) to the deploy pipeline if your deploy does not republish assets — upgrading the package without republishing leaves the vulnerable panel JS in place. The 0.8.0 notes named the wrong tag (--tag=laravel-assets, which publishes nothing for this addon), so any deployment step written from those notes is silently a no-op and should be checked now.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost addon that puts an accessibility check in front of the publish button on our Statamic site, so structural problems — missing headings, unlabelled images, vague link text — get caught by the author instead of by an auditor or a complainant. It reduces the volume of content debt we accumulate and gives us a prioritised, item-level list of what to fix. It is explicitly not a compliance certificate: it does not check colour contrast, and its author is careful not to overclaim. Treat it as one control in an accessibility programme, not the programme itself.

For engineering: Statamic addon, pre-1.0 (currently 0.10.2), single maintainer, public issue tracker only, no response-time commitment. Hooks the existing save pipeline and adds a control panel and Tools page. Requirements include a recent Statamic (README floors reference 6.5) and PHP, with ext-intl adding capability. v0.10.2 fixes a confirmed stored XSS in the control panel: page-derived finding text was rendered via innerHTML, and a heading containing e.g. <img src=/x.png onerror=...> executed in an admin's panel. Upgrade from ≤0.10.1 and republish assets with the addon's own tag; verify any deploy step copied from the 0.8.0 notes, which used the wrong tag and publishes nothing. Also note the release adds a build-time test that checks every CSS class the addon writes against the compiled control-panel stylesheet — a good signal on maintainer rigour, and a pattern worth reusing.

Recommendation: Adopt, pinned to a tested version, behind a pilot with a small author group before enabling as a hard publish gate. Pair it with a manual audit cadence that covers contrast and rendered output. Schedule the 0.10.2 upgrade as a security patch with an explicit asset-republish verification step, not a routine dependency bump.