Web Accessibility Statement Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package — there is no service provider, no vendor:publish, no Blade views. Set expectations accordingly before you composer require it: you are either (a) running it inside a Symfony application/sidecar, or (b) reading it as a reference implementation to port the content model into Laravel.

Where to look first:

1. README.md — install snippet and the configuration example (the fastest way to understand the content model).
2. src/DependencyInjection/Configuration.php — the authoritative list of every statement field you can configure. This is the file a Laravel dev should read closely; it maps 1:1 to what you'd put in config/accessibility.php.
3. src/Resources/config/ — service definitions and the routing file you must import.
4. src/Resources/views/ — the Twig templates; skim for the mandated section order (compliance status, non-accessible content, feedback mechanism, enforcement procedure).

Minimal Symfony setup:

composer require itk-dev/web-accessibility-statement-bundle

// config/bundles.php
ItkDev\WebAccessibilityStatementBundle\WebAccessibilityStatementBundle::class => ['all' => true],

# config/routes.yaml
web_accessibility_statement:
    resource: "@WebAccessibilityStatementBundle/Resources/config/routing.xml"

Then populate the bundle config block (organization, contact point, compliance status, known issues) and hit the generated route. First use case: a public-sector or municipal site that is legally required to publish an accessibility statement — you get a structured, maintainable page instead of hand-maintained HTML that rots.

Implementation Patterns

Configuration as the source of truth. Keep the entire statement in the bundle config, not in templates. Per-environment overrides (e.g. a staging banner, a different feedback e-mail in dev) belong in config/packages/dev/. Treat the config file as a document with an owner — put a last_reviewed date in it and surface it on the page.

Template override, not fork. Override the Twig template via the standard bundle override path (templates/bundles/WebAccessibilityStatementBundle/...) and have it {% extends %} your app layout. This keeps upgrades cheap — which matters, since 2.0.0 was purely a dependency bump.

Symfony → Laravel port shape. If you can't justify a Symfony sidecar, mirror the config tree into Laravel:

// config/accessibility.php  — fields copied from Configuration.php
return [
    'organization' => env('A11Y_ORG', config('app.name')),
    'contact_email' => env('A11Y_CONTACT'),
    'compliance_status' => 'partially-compliant',
    'known_issues' => [],
    'enforcement' => '...',
    'last_reviewed' => '2025-01-01',
];

Then a single invokable controller + Blade partial per section, a named route, and a feature test. Cache the rendered HTML if it's static.

Route and layout integration. If you embed the statement in an existing site, make sure the surrounding layout doesn't reintroduce the problems the statement describes: correct lang attribute, single <h1>, logical heading order, visible focus states, skip link.

Testing. One functional test asserting 200 plus the presence of the four mandated section headings catches 90% of regressions — especially after a template override.

Gotchas and Tips

• 2.0.0 is a breaking release by constraint only. The sole change is the required symfony/framework-bundle version. Nothing in the public API moved. If you're on 1.1.0 and a pinned Symfony, stay put; if you're starting fresh, take 2.0.0. Diagnose with composer why-not itk-dev/web-accessibility-statement-bundle 2.0.0 before assuming a code incompatibility.
• Don't look for Laravel idioms. No package discovery, no publish tags, no config/web-accessibility-statement.php in your app. Any tutorial implying otherwise is for a different package.
• 404 on the statement route almost always means the routing file wasn't imported or the bundle isn't registered — check that before debugging the controller.
• Template-not-found after overriding is a namespace-case issue: the override directory must match the bundle name exactly (templates/bundles/WebAccessibilityStatementBundle/).
• It is not legal advice. The template encodes a specific jurisdictional model (EU/Danish public-sector style). Have your accessibility lead or legal owner validate the wording and the enforcement-procedure section for your country; swapping in a generic "we care about accessibility" blurb defeats the purpose and may not satisfy the regulation.
• Stale statements are a compliance risk. The bundle renders whatever you configure — it does not know your real audit status. Wire a calendar reminder or a CI check that fails if last_reviewed is older than ~12 months.
• Extension points, in order of preference: override templates → override config → decorate the controller service → fork. Each step down costs you more on the next major bump, and bumps here are frequent and dependency-driven.