Statamic Inline Edit Laravel Package

Product Decisions This Supports

• Accessibility compliance as a shippable roadmap item, not a backlog slogan. v1.11.1 maps almost one-to-one onto WCAG 2.2 AA success criteria our buyers ask about: 2.4.7 Focus Visible (solid focus ring on every field, not just wide ones), 2.4.3 Focus Order (focus no longer drops to the top of the page after Escape/Enter, editor close, overlay close, or edit-mode toggle), 1.3.1/4.1.2 Name, Role, Value (aria-labelledby on the select, date input, switch, markdown source box, single-value window), 3.3.1 Error Identification (save errors wrap to a second line instead of truncating at 40 characters), and 4.1.3 Status Messages (role="status" on the status line so "Saved" and every refusal are announced). This is the evidence pack for a VPAT/ACR refresh or a public-sector RFP response.
• Editor adoption and time-to-first-edit. The install story collapses to composer require on a standard Statamic site, with assets auto-published under the addon's own statamic-inline-edit tag. That is a measurable DevEx win: fewer setup steps, fewer "it installed but nothing renders" support tickets, faster trial-to-production.
• Support-cost reduction. Focus management and full error text directly target the two failure modes that generate tickets from non-technical editors: "I lost my place in the page" and "it just said something went wrong and I don't know what." Announcements on save also cut duplicate submissions from users who can't tell whether the save landed.
• Mobile editorial coverage. A save message with its own row above the buttons on phones is a small change that unlocks a real use case — editing on a phone between meetings — without a redesign.
• Build vs. buy. In-house inline editing means owning focus traps, screen-reader labelling, live regions, and asset publishing forever. This release is a strong argument for buy: the vendor is absorbing the accessibility long tail we would otherwise staff.
• Upgrade-risk decision, this cycle. The --force publish behavior is the one item requiring a PM call. Any site that hand-edited files in public/vendor/statamic-inline-edit/ will have those edits silently replaced on every composer install and composer update. We need a decision on moving customizations into our own stylesheet and a communication plan for affected sites before we roll this to customers.
• Roadmap sequencing input. The pattern here — accessibility hardening plus install simplification in a patch release — suggests we can plan around incremental compliance gains rather than waiting for a major version. Worth asking the vendor whether a published conformance statement is on their roadmap; that would change how we position this in regulated deals.

When to Consider This Package

Consider it when:

• The site is Statamic on Laravel with server-rendered front-end templates. That is the supported path; the field markup is what the editor attaches to.
• The primary users are content editors and marketers updating copy, headings, and simple fields, not developers or designers. Inline editing is a workflow win precisely for people who don't want to learn the control panel.
• You sell into or operate in regulated or accessibility-sensitive contexts — public sector, education, healthcare, financial services, EU markets facing the European Accessibility Act. The ARIA labelling, focus visibility, and status-region work in this release are the artifacts procurement will ask to see.
• Onboarding speed matters — agency handoffs, multi-tenant sites, or a large roster of small client sites where composer require as the whole install is a real per-site cost saving.
• You want field-level editing without exposing the full control panel, e.g. giving a client a safe edit surface on a live marketing page.
• You need mobile editing as a genuine scenario rather than a checkbox.

Look elsewhere when:

• The front end is decoupled or headless (Next.js, Nuxt, native apps). There is no rendered Statamic field template for the editor to bind to.
• The application is Laravel but not Statamic. This is an addon, not a general Laravel package.
• Your team maintains a heavily customized fork of the published vendor assets. The --force behavior on install/update means published files are now vendor-owned; if you can't migrate customizations to your own stylesheet, either pin the version or budget the migration.
• You need deep editorial workflow — multi-step approvals, scheduled publishing, granular revision diffs at the field level. Inline editing is a convenience layer, not a workflow engine; use the control panel or a dedicated workflow addon.
• Your deployment model forbids writing to public/ at build time, or assets are served from a CDN with an immutable path. You'll need to handle publishing in CI and version the path yourself.
• Accessibility conformance must be contractually warranted by the vendor. This release improves conformance; it is not a certification.

How to Pitch It (Stakeholders)

For executives: This is a Statamic addon that lets content editors edit the live page in place instead of navigating an admin panel. The new release is an accessibility and install-simplicity release, and both matter commercially. Accessibility: it closes the specific gaps that appear in enterprise and public-sector accessibility reviews — visible keyboard focus on every field, focus that stays where the user was working, screen-reader labelling on every control, and save confirmations and errors that are announced rather than silently displayed. That translates into fewer failed procurement questionnaires and less remediation work we'd otherwise fund ourselves. Install simplicity: on a standard Statamic site, composer require is now the entire install, which shortens onboarding for every new site we stand up. The risk is narrow and known: sites that hand-edited the addon's published front-end files will have those edits overwritten on the next composer install or composer update, so we need a short migration note telling teams to move custom styling into their own stylesheet. Recommended position: adopt, with a targeted upgrade note and a check of our own sites for customized vendor files before rollout.

For engineering: The release is low-risk in code terms and high-value in quality terms. Focus is now explicitly managed across every transition — Escape/Enter in a field, rich editor close, control panel overlay close, and edit-mode toggling from the keyboard — instead of falling back to the top of the document. Controls are labelled via aria-labelledby against their field rather than relying on proximity, and the status line is a live region with role="status", with errors no longer truncated at 40 characters. The one operational change to plan for: the addon's front-end files are published under its own statamic-inline-edit tag, which Statamic publishes with --force after statamic:install. That makes public/vendor/statamic-inline-edit/ vendor-owned territory — treat it as build output, not source. The legacy statamic-inline-edit-assets tag still works for sites that need it, and sites that don't run the publish step from Composer need one command: php artisan vendor:publish --tag=statamic-inline-edit --force. Audit the repo for any tracked edits under that path, move them into our own stylesheet, and add the path to the "do not edit" list in the contributing docs. MARKETPLACE.md dropping out of the Composer package is a packaging cleanup with no runtime impact.