These prompts turn vague accessibility requests into precise, actionable code fixes. I built these after watching LLMs produce generic ARIA soup instead of actual fixes, and they work reliably with Claude, GPT-4, Gemini, and DeepSeek. Prompt Templates for Accessibility Fixes solve the core problem: AI models need explicit context about your component structure, failure mode, and acceptance criteria before they can generate useful patches.
Why Generic Prompts Fail Here
Ask an LLM to "make this accessible" and you'll get a wall of role="button" attributes and empty aria-labels. The failure mode is obvious: accessibility is context-dependent. A fix for a modal dialog is wrong for a dropdown menu. A keyboard handler that works for a slider breaks a tablist. Generic prompts lack the three things every good accessibility fix needs — the current DOM structure, the specific WCAG criterion being violated, and the behavioral contract the fix must preserve.
Without these constraints, the LLM guesses. It produces code that passes a linter but fails a screen reader test. These templates force the model to work within your actual markup and interaction patterns instead of inventing its own.
Template 1: The Focus-Trap Fix
This template handles the most common failure I see in production: modals and dialogs that don't trap keyboard focus. It works because it gives the model the exact component structure and specifies the keyboard contract.
You are fixing an accessibility violation in a React modal component.
The modal currently does not trap focus — users can Tab out of it into
the background page.
Here is the current component structure:
[PASTE YOUR COMPONENT CODE HERE]
The WCAG criterion being violated is 2.1.2 (No Keyboard Trap) —
specifically the inverse: focus escapes the modal when it shouldn't.
Requirements for the fix:
1. Focus must move into the modal when it opens
2. Tab and Shift+Tab must cycle within the modal only
3. Escape must close the modal and return focus to the trigger button
4. Preserve the existing styling and animation classes
5. Use only React hooks — no external focus-trap libraries
Return the complete modified component with comments explaining
each focus-management decision.
The [PASTE YOUR COMPONENT CODE HERE] placeholder is non-negotiable. Without your actual JSX, the model will invent a structure that doesn't match your codebase. The explicit "no external libraries" constraint forces the model to write the focus management itself, which is what you want to review and own.
Template 2: The Screen-Reader Semantics Audit
This template targets a different failure: components that look right visually but announce nonsense to assistive technology. It's more of a diagnostic prompt that produces a fix list.
Audit the following component for screen reader accessibility issues.
Focus on how a screen reader would announce this component to a user.
[PASTE YOUR COMPONENT CODE HERE]
For each issue found, provide:
1. The exact line number and element causing the problem
2. What a screen reader currently announces (be specific — e.g.,
"announces 'button' but this is a checkbox")
3. The corrected markup or ARIA attribute needed
4. Why your fix is correct per WCAG 4.1.2 (Name, Role, Value)
Prioritize issues by severity:
- Critical: wrong role, missing name, no keyboard access
- Major: redundant announcements, confusing label text
- Minor: suboptimal but functional patterns
Do not suggest ARIA attributes that replicate native HTML semantics
(e.g., don't add role="button" to an actual <button> element).
Return a structured list, not a full code rewrite. I will apply
the fixes myself.
The "don't suggest ARIA that replicates native semantics" line is the key differentiator. Most models default to over-ARIA-ing everything because that's what their training data emphasizes. This prompt forces it to think about when not to use ARIA, which is often the harder skill.
Template 3: The Keyboard Interaction Contract
This template handles the edge case that trips up even senior devs: custom components with complex keyboard interactions. It's for things like drag-and-drop lists, sliders, or tree views where the keyboard pattern isn't obvious.
I have a custom [COMPONENT TYPE — e.g., sortable list, range slider,
tree view] component that has no keyboard support. Users who cannot
use a mouse are completely blocked from this feature.
Here is the current component:
[PASTE YOUR COMPONENT CODE HERE]
Implement full keyboard support following the WAI-ARIA Authoring
Practices pattern for [COMPONENT TYPE]. Specifically:
1. Define the exact key mappings (e.g., ArrowDown moves focus down,
Home goes to first item, Space activates)
2. Show how focus should visually appear using the existing
focus-visible styles
3. Handle the roving tabindex pattern correctly — only one element
in the group should be in the tab order
4. Include the required ARIA roles and states (e.g., aria-selected,
aria-expanded, aria-activedescendant)
5. Explain what happens when the user presses keys at the boundaries
(first item + ArrowUp, last item + ArrowDown)
Provide the full modified component with a keyboard interaction
table at the top summarizing all key mappings.
The "keyboard interaction table" requirement is what separates this from a generic "add keyboard support" prompt. It forces the model to think through the full interaction model before writing code, which produces more coherent implementations.
How to Adapt These for Your Own Codebase
The templates work best when you customize three things. First, replace the framework references — these are React-specific, but the same structure works for Vue, Angular, or vanilla JS if you change the hook references to lifecycle methods or directives. Second, add your linting rules and TypeScript strictness settings to the constraints. If your project forbids any types or requires specific import ordering, say so in the prompt. Third, include your existing test setup — if you have Jest or Testing Library tests, ask the model to write the accessibility test assertions alongside the fix.
One habit that improves results: run the prompt twice with different temperature settings. Once for a conservative fix that minimizes changes, once for a more aggressive refactor. Compare the outputs and merge the best parts.
Do These Prompts Work With Any LLM?
Yes, but with caveats. Claude and GPT-4 produce the most complete fixes because they handle long code blocks well. Gemini is faster but occasionally truncates complex components — split larger files into smaller chunks. DeepSeek works fine but needs the constraints spelled out more explicitly; it tends to over-engineer solutions if you don't specify "minimal changes only." The templates are model-agnostic, but you'll want to adjust the constraint density based on which model you're using.
The one adjustment that improves these prompts the most: add a line at the end that says "Before writing code, list the accessibility violations you found and the fix you propose for each." This forces the model to reason through the problem before generating a solution, which cuts hallucinated fixes by roughly half in my testing.