Statamic Bard Assist Laravel Package

Product Decisions This Supports

• Consent & privacy compliance UX: A Laravel package that ships a cookie-consent banner with "Accept all" and granular "pill" toggles sits directly on the GDPR/ePrivacy consent path. PM decisions it informs include whether consent is freely given and unambiguous — which depends on the UI being operable by keyboard, not just pointer.
• Accessibility conformance as a release gate: This patch restores focus to a sensible location after accepting, rather than dropping it to the top of the page. That is the difference between a component that passes a keyboard-only audit and one that fails it. It supports decisions about whether to claim WCAG 2.1/2.2 AA conformance in procurement responses, VPATs, and accessibility statements.
• Regulatory exposure (EAA / ADA / Section 508): The European Accessibility Act obligations for consumer-facing digital services and US ADA web-accessibility litigation both key off keyboard operability. A consent banner is the first interactive component every visitor meets, so a focus-management defect there is disproportionately visible and disproportionately cited in complaints.
• Build vs. buy: Every Laravel app needs consent handling. The realistic alternatives are (a) build a bespoke banner, (b) buy a third-party CMP SaaS (Cookiebot, OneTrust, Osano), or (c) adopt an in-app package like this. This release is evidence for the "buy/adopt" side: the vendor is doing the fiddly focus-management and screen-reader work in-house rather than leaving it to each consuming team.
• Use cases it unlocks: EU/UK-facing marketing sites, SaaS sign-up funnels, public-sector Laravel deployments with accessibility procurement requirements, and any product where legal has asked for "proof the consent UI is accessible."
• Roadmap signal: A patch release dedicated solely to focus restoration indicates the maintainer treats a11y as a correctness issue, not a nice-to-have. That raises confidence in betting a compliance-adjacent surface on this dependency.

When to Consider This Package

Consider it when:

• You are shipping a Laravel app to EU/UK users and need a consent interface you can wire into your own controllers, views, and consent-log persistence rather than redirecting users to a vendor's hosted CMP.
• Accessibility is a contractual or procurement requirement — public sector, enterprise security review, or an existing VPAT — and you need keyboard and screen-reader behaviour handled by the component rather than by your team.
• You want consent state to live in your own database and session, so legal can audit it without a third-party data processor in the chain (a meaningful GDPR data-minimisation argument).
• Your front end is server-rendered Blade or lightly enhanced with Alpine/Livewire; the "pill" toggle pattern implies a componentised UI that expects to own its own DOM subtree.
• You have a small team and no dedicated accessibility specialist to hand-roll focus traps and restoration.

Look elsewhere when:

• You need multi-jurisdiction consent string formats (IAB TCF v2.2), Google Consent Mode v2 signalling, or tag-manager orchestration. That is CMP-SaaS territory; this package is not positioned as one, and stretching it there creates compliance risk.
• You require a vendor with a support SLA, indemnification, or a SOC 2 report. A community Laravel package gives you none of those, and consent is a surface legal will ask about.
• Your front end is a decoupled SPA or mobile app — the Blade-coupled assumptions and DOM-focused focus handling will not transfer.
• Your design system mandates a fully custom consent UI with no room for an opinionated markup structure.
• You need documented, versioned a11y conformance evidence (an ACR/VPAT) rather than a changelog line item. A focus fix is reassuring but is not a certification.

Maturity caveat: at v1.0.2 the package is young. A single-item accessibility patch at this stage is normal and healthy, but it also means the keyboard and screen-reader surface has not been through many rounds of real-world use. Budget for your own manual keyboard and VoiceOver/NVDA pass before relying on it in a regulated context.

How to Pitch It (Stakeholders)

For executives: We are evaluating a small Laravel package that provides the cookie-consent banner in our app. It keeps consent records in our own database — no additional third-party data processor — and the maintainer has just shipped a fix so that keyboard and assistive-technology users can actually operate the banner. That matters because consent obtained through an interface a disabled user cannot operate is consent legal counsel will have difficulty defending, and because accessibility is now an explicit regulatory obligation in the EU and a routine litigation target in the US. The cost is a Composer dependency; the alternative is either a bespoke build (weeks of engineering plus ongoing a11y maintenance) or a CMP subscription (recurring spend plus a new processor in our data map). Recommendation: adopt for EU/UK-facing Laravel surfaces, contingent on our own keyboard and screen-reader verification, and do not attempt to stretch it into a full consent-management platform.

For engineering: This is a server-rendered consent component for Laravel — banner plus granular per-purpose toggles, with consent state persisted on our side. v1.0.2 fixes focus management: after "Accept all" or confirming a toggle with Enter, focus now returns to the originating text position instead of falling to the document body. That is a real keyboard-navigation bug, not cosmetics — it is the class of defect that makes a banner unusable without a mouse, and it is the kind of thing that shows up first in an accessibility audit. The integration surface is small and the failure mode is contained. Before we commit: pin the version, run a manual tab/Enter pass and a VoiceOver or NVDA pass on our actual templates, and confirm the focus-restoration behaviour survives our CSS resets and any modal or overlay we wrap around it. Flag for legal review that this is an open-source package at v1.0.2 with no vendor SLA — if we need Consent Mode or TCF strings later, that is a re-platforming decision, not a config change.