Prompts for Accessible Components: Getting AI to Build WCAG-Compliant UI

The Accessibility Gap in AI-Generated Code

LLMs know WCAG guidelines. They can explain them accurately. But in generated code, accessibility is consistently underprioritized unless you explicitly ask for it. Without accessibility constraints in your prompt, you'll get visually correct components that fail keyboard navigation, screen readers, and color contrast checks.

The Accessibility Constraint Block

Add this block to any component generation prompt:

Accessibility requirements (WCAG 2.1 AA compliance):

1. Keyboard navigation:
   - All interactive elements reachable by Tab
   - Enter/Space activates buttons
   - Escape closes modals/dropdowns/overlays
   - Arrow keys navigate within component (menus, tabs, lists)
   - Focus is managed correctly when content appears/disappears

2. Screen reader support:
   - Semantic HTML (button not div, nav not div, etc.)
   - Meaningful aria-label on icon-only elements
   - role attributes where semantic HTML insufficient
   - aria-expanded on accordion/dropdown triggers
   - aria-live for dynamic content updates
   - aria-describedby linking errors to inputs

3. Visual:
   - Focus indicator visible (ring-2 ring-blue-500 ring-offset-2, not outline-none)
   - Color contrast: 4.5:1 for normal text, 3:1 for large text
   - Don't communicate information by color alone

4. Structure:
   - Proper heading hierarchy within component
   - Lists use ul/ol/li, not div soup

Accessible Modal Prompt Example

Build an accessible modal dialog component in React + TypeScript.

Apply all WCAG 2.1 AA requirements:
- Focus trap: when open, Tab cycles only through modal content
- Focus returns to trigger when closed
- aria-modal="true" and role="dialog"
- aria-labelledby pointing to modal title
- Escape key closes it
- Click backdrop closes it
- Scroll lock on body when open
- Announce opening to screen readers

Props:
interface ModalProps {
  open: boolean;
  onClose: () => void;
  title: string;
  children: React.ReactNode;
  size?: "sm" | "md" | "lg";
}

Use the native HTML dialog element if appropriate, or a custom implementation that matches its accessibility semantics.

Accessible Form Field Prompt

Build an accessible form field component that wraps a text input.

Accessibility requirements:
- Input and label must be associated via htmlFor/id
- Error message linked to input via aria-describedby
- Required fields use aria-required, not just HTML required
- Invalid state uses aria-invalid="true"
- Helper text is included in aria-describedby
- Placeholder is NOT used as a label substitute

Props:
interface FieldProps {
  label: string;
  name: string;
  error?: string;
  hint?: string;
  required?: boolean;
  // ...standard input props
}

The error message must be announced by screen readers when it appears.

Testing Accessibility With Prompts

Review this component for accessibility issues.

For each issue found:
1. Identify the WCAG criterion violated (include the number, e.g., 2.1.1)
2. Explain the user impact (who is affected and how)
3. Provide the specific code fix

[PASTE COMPONENT]

Automating Accessibility Checks

Combine AI accessibility prompts with automated tools. Use axe-core or jest-axe in your test suite for regression testing. AI catches structural and semantic issues; automated tools catch measurable ones like contrast ratios and missing labels.

import { axe } from 'jest-axe';

test('Modal has no accessibility violations', async () => {
  const { container } = render(
    <Modal open title="Test">Content</Modal>
  );
  const results = await axe(container);
  expect(results).toHaveNoViolations();
});