accessibility-compliance

Run automated accessibility audit on a page or template

Reviews CSS changes for WCAG 2.2 visual accessibility compliance. Use proactively after any CSS modification, color token changes, animation additions, focus style updates, or responsive layout changes. Checks color contrast ratios, focus visibility, reduced motion support, forced-colors compatibility, text spacing resilience, and reflow at zoom levels. <example>Context: The user modified color tokens. user: "I updated the color scheme for the dashboard" assistant: "Let me use the a11y-css-reviewer to verify the new colors meet WCAG AA contrast requirements." <commentary>Color changes are the most common source of contrast failures. Every color pair needs verification.</commentary></example> <example>Context: The user added an animation. user: "I added a fade-in animation to the hero section" assistant: "I'll run the a11y-css-reviewer to check the animation respects prefers-reduced-motion." <commentary>All animations must be wrapped in motion-safe media queries.</commentary></example> <example>Context: The user changed focus styles. user: "I updated the focus ring to match the new brand colors" assistant: "Let me verify the focus indicators meet WCAG 2.4.7 and 2.4.13 requirements with the a11y-css-reviewer." <commentary>Focus indicators must be visible and meet contrast requirements against adjacent colors.</commentary></example>

Reviews Datastar interactions, SSE responses, and JavaScript-driven DOM updates for accessibility compliance. Use proactively after adding Datastar attributes, SSE endpoints, partial page updates, client-side state changes, or any dynamic content behavior. Checks live region announcements, focus management after morphing, loading state communication, interactive element semantics, and keyboard operability of dynamic widgets. <example>Context: The user added Datastar-driven form submission. user: "I hooked up the proposal form to submit via Datastar SSE" assistant: "Let me use the a11y-dynamic-content-reviewer to verify the form announces success/error states and manages focus after morph." <commentary>Datastar SSE responses morph the DOM — screen readers need live regions and focus must be managed explicitly.</commentary></example> <example>Context: The user added real-time content updates. user: "The dashboard now updates vote counts via SSE" assistant: "I'll run the a11y-dynamic-content-reviewer to check that vote count changes are announced to screen readers." <commentary>Silent content updates are invisible to screen reader users without aria-live regions.</commentary></example> <example>Context: The user added a tab interface with Datastar. user: "I built the settings tabs using Datastar signals" assistant: "Let me verify the tab widget has proper ARIA roles and keyboard navigation with the a11y-dynamic-content-reviewer." <commentary>Custom widgets built with Datastar need ARIA roles, states, and keyboard interaction patterns matching the APG.</commentary></example>

Reviews HTML, Templ, and Twig templates for WCAG 2.2 accessibility violations. Use proactively after any template modification, new page creation, form changes, navigation updates, or component additions. Checks semantic structure, heading hierarchy, ARIA attributes, form labeling, image alt text, link text quality, landmark regions, and keyboard operability patterns. <example>Context: The user created a new Templ page template. user: "I built the member profile page" assistant: "Let me use the a11y-html-reviewer agent to check the template for accessibility compliance." <commentary>New page templates need landmark verification, heading hierarchy, and form accessibility checks.</commentary></example> <example>Context: The user modified a Twig template in a Craft CMS project. user: "I updated the news entry template to show related articles" assistant: "I'll run the a11y-html-reviewer to verify the heading levels, link text, and image alt attributes in the updated template." <commentary>Template changes often introduce heading hierarchy breaks and generic link text like 'Read more'.</commentary></example> <example>Context: The user added a form to a page. user: "I added the proposal submission form" assistant: "Let me run the a11y-html-reviewer to check form labeling, error handling, and required field announcements." <commentary>Forms are the most common source of accessibility failures — labels, errors, and fieldsets all need verification.</commentary></example>

Runs automated accessibility audits against running applications using Pa11y, axe-core, and Playwright. Use when the user wants to scan pages for WCAG violations, run a11y checks before deployment, verify accessibility fixes, or generate compliance reports. Coordinates automated scanning, interprets results, and provides remediation guidance. <example>Context: The user wants to check their app for accessibility issues. user: "Run an accessibility audit on the dashboard" assistant: "I'll use the a11y-audit-runner to scan the dashboard for WCAG 2.2 AA violations." <commentary>Automated scanning catches ~40% of issues — run this first, then follow up with manual testing.</commentary></example> <example>Context: The user just fixed several accessibility issues. user: "Can you verify my a11y fixes are working?" assistant: "I'll run the a11y-audit-runner to confirm the violations are resolved." <commentary>Re-scanning after fixes verifies remediation and catches any regressions.</commentary></example>

Sets up accessibility testing infrastructure in new or existing projects. Installs Pa11y and axe-core, creates test configurations, adds CI pipeline steps, configures hooks for accessibility enforcement, and generates starter test files. Use when scaffolding a new project, adding a11y testing to an existing project, or configuring CI pipelines for accessibility. <example>Context: The user is setting up a new Go+Templ+Datastar project. user: "Set up accessibility testing for my new Assembly project" assistant: "I'll use the a11y-project-setup agent to install testing tools, create configurations, and set up hooks for accessibility enforcement." <commentary>New projects need Pa11y config, Playwright tests, CI pipeline, and hooks from day one.</commentary></example> <example>Context: The user wants to add a11y testing to an existing Craft CMS project. user: "Add accessibility checking to our existing site" assistant: "I'll run the a11y-project-setup agent to add testing infrastructure without disrupting the existing workflow." <commentary>Existing projects need testing tools added alongside current infrastructure.</commentary></example>

Test web applications with screen readers including VoiceOver, NVDA, and JAWS for accessibility compliance. Use when validating screen reader compatibility, debugging accessibility issues, ensuring assistive technology support, writing ARIA markup, verifying live region announcements, or testing keyboard navigation with screen readers. Also use when a new interactive component is built and needs manual verification, when automated a11y tools report no issues but you suspect screen reader problems, or when reviewing Templ components, Twig templates, or Datastar-enhanced pages for screen reader compatibility. Covers VoiceOver (macOS), NVDA (Windows), testing protocols, and common failure patterns.

Conduct WCAG 2.2 accessibility audits with automated testing, manual verification, and remediation guidance for Live Wires, Go+Templ+Datastar, and Craft CMS projects. Use when auditing websites for accessibility, fixing WCAG violations, reviewing HTML templates for a11y compliance, checking color contrast, validating focus management, adding ARIA attributes, or preparing for EAA/ADA compliance. Also use when writing new Templ components, Twig templates, or Datastar-enhanced pages that need accessible markup patterns. Covers WCAG 2.2 Level AA, ARIA Authoring Practices, automated tooling, and stack-specific patterns.