What this prompt does
This prompt sets up automated accessibility testing for a [framework] application targeting WCAG [wcag_level]. It integrates axe-core with your [test_runner] for every page and component, adds keyboard-navigation tests for tab order and focus management, validates color contrast across [theme_count] themes, and checks ARIA attributes on your [custom_components]. The aim is to make accessibility a gate on every PR rather than an afterthought.
It works because accessibility regressions are easy to introduce and hard to spot by eye, so automation catches what humans miss. It adds screen-reader announcement testing with [screen_reader_tool], alt-text presence and quality checks, and form accessibility validation for labels and error messages, then fails the build on [severity] or higher violations in CI. Because tooling can't catch everything, it also produces a manual testing checklist for the judgment-based issues, with worked examples for [example_page] so the setup is concrete rather than theoretical.
When to use it
- Accessibility is a real requirement and you want it enforced on every PR
- You need axe-core scans wired into CI for a
[framework]app - Custom components like
[custom_components]need ARIA and keyboard testing - You support multiple themes and must check contrast across
[theme_count]of them - You want the build to fail on
[severity]-or-higher violations - You need a manual checklist for the accessibility issues automation can't detect
Example output
You get a testing setup: axe-core wired into [test_runner] for pages and components, keyboard-navigation tests for tab order, focus and skip links, contrast validation across [theme_count] themes, ARIA checks for [custom_components], screen-reader announcement tests via [screen_reader_tool], alt-text presence and quality checks, form-accessibility tests for labels and errors, a CI gate failing on [severity]+ violations, a report with remediation guidance, a manual checklist, and example tests for [example_page].
Pro tips
- Set
[wcag_level]to your real compliance target (2.1 AA is common) since it determines which rules axe-core enforces - List your actual
[custom_components]because custom widgets are where ARIA regressions hide, not standard HTML elements - Pick a
[severity]threshold you'll hold the line on; failing the build on serious-and-above keeps the gate meaningful without blocking on minor nits - Treat automated checks as a floor — axe-core catches a subset of issues, so the manual checklist for things like logical reading order still matters
- Test contrast across all
[theme_count]themes; a palette that passes in light mode can quietly fail in dark mode - Validate screen-reader announcements with
[screen_reader_tool], since correct ARIA attributes can still produce confusing spoken output - Check that every form field has a programmatic label and that error messages are announced, since broken forms block users more than any other accessibility gap
- Use a realistic
[example_page]like a checkout form so the example tests transfer to your hardest real screens
