Weave Code
Accessibility Laravel Package
artisanpack-ui/accessibility
Ensure accessible color contrast in Laravel apps. Check text/background contrast, auto-generate readable text colors from hex, Tailwind, RGB, or HSL values, and manage user accessibility preferences with simple Blade-friendly helpers.
Build inclusive and compliant web applications with essential tools that empower you to create experiences usable by everyone, seamlessly integrated into your Laravel projects. This package provides accessibility tools and features designed to help developers create web applications that are inclusive and compliant with accessibility standards.
Frequently asked questions about Accessibility
- How do I install artisanpack-ui/accessibility in a Laravel application?
- Run composer require artisanpack-ui/accessibility and the service provider is auto-discovered, so no manual registration is needed. The package requires PHP 8.2 or 8.3 and Laravel 11.44.1+, 12, or 13. For a minimal adoption, install a pinned constraint such as 2.1.* and skip publishing the config file or running the enterprise migration unless you actually plan to use the reporting features.
- What Laravel and PHP versions does artisanpack-ui/accessibility support?
- Version 2.1.2 requires illuminate/support ^11.44.1|^12.0|^13.0 and PHP 8.2 or 8.3. Laravel 10 and PHP 8.1 are not supported. Because the framework constraint is a hard requirement, the package participates in your Laravel upgrade path and can block patch-level framework upgrades in tightly pinned environments.
- How do I automatically pick a readable text color for a background color in Blade?
- Use the global helper a11yGetContrastColor('#3b82f6'), which returns a readable text color for the supplied background. A common pattern is calling it in a Blade component constructor and passing both values into the view, so a button or badge always gets the correct foreground. The README shows this exact setup for a Button component that accepts hex, rgb(), or Tailwind color values.
- Which color formats does the contrast checker support?
- The package accepts hex values, Tailwind CSS color names, rgb(), and hsl() strings. Alpha channels, CSS custom properties, and oklch() are not documented, so convert those to plain hex before passing them in. If you use CSS variables for theming, resolve them to concrete values server-side first.
- Why does Tailwind color contrast come out wrong with my customized tailwind.config.js palette?
- Tailwind support appears to resolve color names through a static palette map shipped in resources/tailwind-colors.php, not by reading your tailwind.config.js. If you have customized or extended the default palette, the package can silently return the wrong contrast decision for a given class name. Pass raw hex values instead of Tailwind class names whenever your theme differs from the stock palette.
- Which license applies to artisanpack-ui/accessibility, MIT or GPL-3.0-or-later?
- The metadata is inconsistent: the listing says MIT while the README states GPL-3.0-or-later. That distinction matters, because GPL-3.0 is copyleft and is generally unsuitable for closed-source or commercially distributed applications. Resolve the license with your legal team before any code lands in a production codebase.
- Do I need to publish the config file or run migrations after installing?
- No. Config publishing and the enterprise database migration are opt-in, and for contrast checking alone you should skip both. Note that in v2.1.1 the config namespace moved from accessibility.* to artisanpack.accessibility.* and the published path is now config/artisanpack/accessibility.php, so any older snippets you find online will not match. Only run the migration if you are deliberately evaluating the reporting and audit features.
- Is it safe to upgrade artisanpack-ui/accessibility across minor versions?
- Treat upgrades with caution. The v2.1.1 config namespace and published path change was a breaking change shipped on a minor release, which suggests patch and minor upgrades may not be drop-in safe. Pin an exact or narrow constraint like 2.1.* and re-verify contrast behavior after each bump, especially if you have published configuration.
- Can I rely on the package's compliance reports or certificate generator for WCAG compliance?
- No. The 2.0 release added reporting, trend analysis, and a CertificateGenerator, but no software package can grant legal assurance of accessibility compliance. Use contrast checks as one input to your own audit and validate against the W3C reference test vectors. Treat the reporting suite as unvetted breadth rather than a compliance guarantee.
- Is there a facade or service class instead of the global helper, and is the package actively maintained?
- The documented stable API is the global a11yGetContrastColor() helper, which pollutes the global function namespace and makes substitution harder than an injectable service or facade. Ask the maintainer whether a supported service contract exists before depending on anything beyond the helper. Given zero stars, zero dependents, and an unresolved license question, plan a fallback: the WCAG relative-luminance math is small enough to implement directly if the package stalls.
Weaver
How can I help you explore Laravel packages today?