Accessible Forms Laravel Package

Product Decisions This Supports

• Build vs. buy on form accessibility. Rather than hand-rolling accessible markup (labels, error summaries, fieldset/legend grouping, ARIA wiring) in every form, this package centralises it. The PM decision is whether accessible form rendering is a differentiator (build) or undifferentiated compliance plumbing (buy/adopt).
• Compliance roadmap: WCAG 2.2 / ADA / Section 508 / European Accessibility Act. Accessibility conformance is increasingly a legal requirement with deadlines, not a nice-to-have. A maintained package with a release cadence reduces the audit surface your team owns.
• Security hardening roadmap (the v0.3.0 unlock). The new optional nonce parameter for inline JavaScript means the package's client-side behaviour can run under a strict Content-Security-Policy without resorting to unsafe-inline. This moves the package from "blocked by our security posture" to "deployable." For any org with a CSP mandate, a security review gate, or a pen-test finding on inline scripts, this is the release that makes adoption viable.
• Feature scoping for internal design systems. If you maintain a component library, this package tells you which accessible-form patterns you can inherit instead of specifying and maintaining yourself — useful input to design-system backlog prioritisation.
• Upgrade-risk triage. v0.3.0 is additive and optional (a new parameter), so it does not force a migration. That makes it a low-risk candidate to slot into a routine dependency bump rather than a dedicated sprint.

When to Consider This Package

Consider adoption when:

• You are on Laravel and ship public-facing or regulated forms (signup, checkout, benefits/claims, government or healthcare intake) where accessibility failures carry legal or reputational cost.
• Your platform enforces or is moving toward a Content-Security-Policy, particularly one that disallows unsafe-inline. Before v0.3.0 this package would have been a CSP blocker; with the nonce parameter it is a candidate. Confirm your CSP plumbing can actually pass a per-request nonce into the package's render path.
• Your team lacks deep ARIA and screen-reader expertise, so correct-by-default markup has more value than bespoke control.
• You want reduced audit burden: a smaller, better-understood surface for an external accessibility audit to review.
• You are pre-0.4 and accept some API churn in exchange for early influence on the package's direction.

Look elsewhere or defer when:

• You are not on Laravel, or your forms are rendered client-side by a SPA framework — the value proposition is tied to server-rendered Blade output.
• You already have a mature, audited internal form component library. Adopting a second source of truth for form markup creates divergence and doubles audit scope.
• Your CSP uses hashes rather than nonces, or your nonce injection happens at the edge/proxy in a way that won't reach this package's inline script — verify before committing.
• You need long-term vendor guarantees. At v0.3.0 this is pre-1.0 with a single maintainer organisation; treat it as a dependency with real bus-factor risk.
• Forms are not a meaningful part of your product surface — the integration and review cost won't amortise.

Diligence before committing: the assessment above is derived from release notes only. Before adoption, read the README and source to confirm the actual pattern coverage (error summaries, conditional fields, multi-step forms) and confirm the nonce is applied to all inline script emissions, not just one code path. Add an accessibility regression test (axe-core or similar) to your CI so a future minor release cannot silently degrade conformance.

How to Pitch It (Stakeholders)

For executives: Accessible forms are a legal exposure and a conversion issue — inaccessible fields cause real users to abandon transactions. This package is a small, low-cost dependency that gives us correct accessible form markup by default instead of rebuilding it in-house. The latest release (v0.3.0) removes the main blocker to adopting it: our security policy bans inline JavaScript, and the package now supports a per-request nonce so it can run under our strict CSP. It is an additive, optional change with no migration required, so the cost of trying it is a dependency bump plus a review, not a project.

For engineering: v0.3.0 adds an optional nonce parameter to the package's inline JavaScript, enabling CSP compliance without unsafe-inline. The change is backwards compatible — existing calls are unaffected. Suggested path: (1) verify our nonce generation can be threaded into the package's render call; (2) confirm the nonce is applied to every inline script the package emits; (3) pilot on one low-traffic public form; (4) add an automated accessibility check plus a CSP violation report check to CI before wider rollout. Be aware we are pre-1.0 — pin the version and review each release's changelog rather than floating the constraint.