# Accessibility Acceptance Criteria Builder

Turn a feature brief into concrete accessibility behavior, acceptance criteria, and tests that an AI coding assistant can implement and verify.

## Prompt

You are an accessibility-focused frontend architect who specializes in testable inclusive interaction requirements.

Inputs:
1. Feature, users, and primary tasks: {{feature_context}}
2. Planned interface, components, and interactions: {{interface_design}}
3. Content, media, validation, and dynamic updates: {{content_and_states}}
4. Platforms, frameworks, and assistive technology targets: {{technical_context}}
5. Accessibility standard, supported browsers, and constraints: {{constraints}}

Do the following:
1. Map the feature into semantic structure, accessible names, relationships, reading order, focus order, keyboard commands, pointer alternatives, and expected assistive-technology announcements.
2. Define behavior for zoom, reflow, contrast, color independence, target size, text spacing, reduced motion, high contrast, localization, errors, status updates, and time limits where relevant.
3. Write specific Given-When-Then acceptance criteria for every meaningful interaction and state, including loading, empty, validation, error, success, disabled, and permission-limited conditions.
4. Separate checks suitable for automated tools from keyboard, screen-reader, zoom, visual, cognitive, and user testing, and identify the limitations of automation.
5. Produce an accessibility specification, acceptance-criteria table, implementation notes, test matrix, manual test script, and definition-of-done checklist. Do not claim conformance based only on automated scans.

## Best for

Vibe coders who need implementation-ready accessibility requirements before asking an AI assistant to build a feature.

## Compatible tools

- Claude
- ChatGPT

## How to use

- Describe every interaction and dynamic state.
- Name the accessibility standard and target technologies.
- Include non-pointer alternatives for gestures.
- Turn the criteria into the coding prompt and definition of done.

## Customization tips

- Use Given-When-Then behavior for complex interactions.
- Specify focus destination after every dialog or deletion.
- Test zoom and reflow with realistic content.
- Do not rely on automated accessibility tools alone.

## Example input

Feature: Drag-and-drop lesson planner for teachers. Interface: lessons can be reordered between weekdays, edited in a modal, duplicated, and deleted with undo. Content: dynamic save status and validation for overlapping times. Stack: React and dnd-kit. Targets: keyboard, NVDA with Firefox, VoiceOver with Safari, 400% zoom, and WCAG 2.2 AA. Constraint: drag behavior must also work without a pointer.

## Example output

The criteria require semantic day lists, visible and announced item position, keyboard pickup, movement, drop, and cancel controls, plus non-drag move actions. Focus returns to the initiating lesson after modal close or undo. Overlap errors are linked to fields and summarized, while save status uses a polite live region without repeated noise. The matrix separates axe checks from manual keyboard, NVDA, VoiceOver, zoom, reduced-motion, and high-contrast testing.