Accessibility Compliance Gate Prompt

Use this prompt when your product pipeline generates UI components, page layouts, or content blocks through an AI model and you need a structured compliance gate before those artifacts reach production. This playbook is built for frontend engineering teams, content operations engineers, and accessibility specialists who must enforce WCAG 2.2 Level AA or Section 508 conformance without manually reviewing every AI output. The prompt produces a pass, fail, or needs-human-review decision with specific success criterion references, violation severity, and remediation guidance. It does not replace automated accessibility testing tools like axe-core or Lighthouse. Instead, it acts as a pre-tool gate that catches structural and semantic issues automated scanners miss, such as heading hierarchy violations, missing ARIA roles on custom widgets, color contrast intent, and focus order logic. Wire this prompt into your CI/CD pipeline, content approval workflow, or design system governance process as a blocking check before automated tests run.

The ideal user is an engineering lead or platform engineer responsible for AI output quality gates. They have access to the raw AI-generated HTML, component code, or content payload, and they need a consistent, auditable compliance signal before the artifact proceeds to browser-based testing. The prompt requires the artifact itself, the applicable standard (WCAG 2.2 AA or Section 508), and optionally a component type hint to focus the analysis. Do not use this prompt for runtime DOM analysis of live pages—that is the job of axe-core. Do not use it for color contrast ratio calculations, which require pixel-level computation. Instead, use it to catch intent-level failures: a <div> with an onClick handler that lacks role="button", a heading that jumps from <h1> to <h3>, or an image with a placeholder alt attribute. These are the violations that survive automated scans and accumulate into real user harm.

Before integrating this prompt into a blocking gate, run it against a golden set of 20–30 known-clean and known-violating artifacts to calibrate its sensitivity. False negatives—passing a component that contains a real WCAG failure—are more dangerous than false positives, so tune your eval thresholds to favor needs-human-review over pass when the model is uncertain. Pair this prompt with a structured output schema that includes violations as an array of objects, each with criterion_id, severity, element, and remediation. Log every gate decision with the artifact hash, model version, and timestamp so you can audit decisions later. If the prompt flags a needs-human-review, route the artifact to a review queue with the full violation context attached—never silently pass it.

This prompt template is designed for injection as a system or developer message in a compliance gate pipeline. It instructs the model to act as an accessibility compliance auditor, evaluating a proposed [COMPONENT_OR_CONTENT] against the provided [WCAG_VERSION] and [STANDARD] criteria. The output is a structured JSON gate decision that can be parsed by downstream orchestration logic to either allow the workflow to proceed, block it for remediation, or flag it for human review. The template uses square-bracket placeholders for all dynamic inputs, ensuring it can be adapted to different accessibility standards, risk tolerances, and output schemas without modifying the core instruction logic.

textCopy
You are an accessibility compliance auditor. Your task is to evaluate the following [COMPONENT_OR_CONTENT] against [WCAG_VERSION] Level [CONFORMANCE_LEVEL] and [STANDARD] requirements.

## INPUT
[COMPONENT_OR_CONTENT]

## CONTEXT
- Component Type: [COMPONENT_TYPE]
- User Context: [USER_CONTEXT]
- Platform: [PLATFORM]
- Assistive Technology: [ASSISTIVE_TECHNOLOGY]

## CONSTRAINTS
- Only evaluate against the success criteria explicitly listed in [WCAG_VERSION] Level [CONFORMANCE_LEVEL].
- Do not invent or assume success criteria that are not part of the specified standard.
- If the component relies on dynamic behavior or complex state changes, flag it for manual review rather than making assumptions.
- For any violation, cite the specific success criterion identifier and provide a concise description of the failure.
- If insufficient information is provided to evaluate a criterion, mark it as "INSUFFICIENT_DATA" rather than passing or failing.

## OUTPUT_SCHEMA
Return a single JSON object with the following structure:
{
  "gate_decision": "PASS" | "FAIL" | "NEEDS_REVIEW",
  "summary": "One-sentence summary of the overall assessment.",
  "violations": [
    {
      "criterion_id": "e.g., 1.1.1",
      "criterion_name": "e.g., Non-text Content",
      "severity": "CRITICAL" | "MAJOR" | "MINOR",
      "description": "Specific description of the failure.",
      "location": "Identifier for the affected element or region.",
      "remediation": "Actionable guidance to fix the violation."
    }
  ],
  "warnings": [
    {
      "criterion_id": "...",
      "description": "Potential concern that does not clearly fail but warrants attention."
    }
  ],
  "needs_review_reasons": [
    "Reason why human review is required, if applicable."
  ],
  "insufficient_data_criteria": [
    "List of criterion IDs that could not be evaluated due to missing information."
  ]
}

## RISK_LEVEL
[RISK_LEVEL]

## EXAMPLES
[EXAMPLES]

## INSTRUCTIONS
1. Analyze the [COMPONENT_OR_CONTENT] against each applicable success criterion.
2. For each violation, provide the structured output as defined in OUTPUT_SCHEMA.
3. If [RISK_LEVEL] is "HIGH", any CRITICAL violation must result in a "FAIL" gate decision.
4. If [RISK_LEVEL] is "LOW", only CRITICAL violations that affect core functionality should result in "FAIL"; others may result in "NEEDS_REVIEW".
5. If you are uncertain about a violation or the component involves complex interactive behavior, set gate_decision to "NEEDS_REVIEW" and populate needs_review_reasons.
6. Do not include any text outside the JSON object.

To adapt this template for your pipeline, replace each square-bracket placeholder with concrete values before execution. The [COMPONENT_OR_CONTENT] placeholder should receive the raw UI markup, content fragment, or component description to be evaluated. [WCAG_VERSION] and [CONFORMANCE_LEVEL] define the evaluation standard (e.g., "WCAG 2.2" and "AA"). [STANDARD] allows you to specify additional frameworks like "Section 508". The [RISK_LEVEL] placeholder controls the strictness of the gate decision: use "HIGH" for customer-facing production workflows where accessibility failures carry legal or reputational risk, and "LOW" for internal tools or early-stage prototypes where the goal is awareness rather than enforcement. The [EXAMPLES] placeholder should be populated with few-shot demonstrations of correct evaluations for your specific component types, which significantly improves accuracy on complex UI patterns. After the model returns the JSON, validate the output against the schema before acting on the gate decision. For any "NEEDS_REVIEW" or "FAIL" decision, route the full violation payload to your human review queue or remediation pipeline. Never execute a blocked workflow without documented override justification.

This prompt is designed to act as a blocking gate, not a passive linter. It should be integrated directly into the path that publishes or deploys UI components, content fragments, or design system changes. The harness must treat a status: "FAIL" or status: "NEEDS_REVIEW" as a hard stop that prevents the artifact from progressing to production. Because accessibility failures carry legal and reputational risk, the implementation must produce an auditable record of every gate decision, including the model's reasoning, the specific success criteria cited, and the remediation guidance provided.

Wire the prompt into your application by placing it after the AI generation step and before any deployment or publish action. The harness should: (1) assemble the prompt with the [COMPONENT_SPEC] or [CONTENT_PAYLOAD] and the [TARGET_STANDARD] (e.g., WCAG 2.2 AA); (2) call the model with a low temperature (0.0–0.1) to maximize deterministic, repeatable assessments; (3) parse the JSON output and validate the schema strictly—reject any response missing required fields like status, violations, or remediation; (4) on parse failure, retry once with a repair prompt that includes the raw output and the expected schema; (5) if status is FAIL, block the pipeline and surface the violations array and remediation guidance to the developer or content author; (6) if status is NEEDS_REVIEW, route the assessment to a human review queue with the full payload, the model's reasoning, and a link to the relevant WCAG success criterion documentation; (7) log the full prompt, response, and gate decision to an audit store for compliance evidence. For high-throughput pipelines, consider caching assessments for identical component signatures to avoid redundant API calls.

The most dangerous failure mode in production is a false pass on complex interactive components—dynamic widgets, modal dialogs, custom select elements, or drag-and-drop interfaces. The model may assess static markup as compliant while missing keyboard trap issues, focus order problems, or missing ARIA live region announcements. To mitigate this, the harness should maintain a registry of known complex component types and automatically escalate any assessment involving them to NEEDS_REVIEW regardless of the model's confidence score. Additionally, implement a sampling-based eval loop: periodically pull gate decisions, have a human accessibility specialist review a random sample, and feed any false passes back as counterexamples in the prompt's [EXAMPLES] block. Do not allow the gate to be silently bypassed with an override flag that lacks a required justification field—every override must capture who approved it, why, and what compensating controls are in place.