Best AI Prompts for Accessibility Audits with Claude

TL;DR

• Claude’s analytical capabilities make it particularly strong for complex accessibility analysis, including interpreting WCAG success criteria across multiple page types simultaneously.
• The shift-left accessibility approach — integrating accessibility review into the design and development process — is more efficient than auditing and fixing post-development.
• Claude excels at evaluating accessibility across entire page hierarchies rather than individual components in isolation.
• WCAG 2.2 introduced new success criteria that many organizations are not yet compliant with — Claude can help identify where these new requirements apply.
• Accessibility audit results are only valuable when they produce actionable remediation — Claude can help prioritize and plan fixes.

Introduction

Accessibility auditing has traditionally been a specialized discipline requiring deep knowledge of WCAG criteria, assistive technology behavior, and screen reader interaction patterns. This expertise has been in short supply, which is why most organizations audit accessibility infrequently, fix issues in large batches after design and development are complete, and struggle to maintain compliance as their products evolve.

Claude changes this equation by functioning as an always-available accessibility expert that can review code, interpret WCAG requirements, evaluate entire page hierarchies for structural accessibility issues, and generate actionable remediation plans. The shift-left approach — using Claude to catch accessibility issues during design and development rather than after — is where AI-assisted accessibility work delivers the highest return.

Table of Contents

1. The Shift-Left Accessibility Approach
2. Claude for WCAG 2.2 Compliance
3. Component-Level Accessibility Review
4. Page Hierarchy and Navigation Accessibility
5. Dynamic Content and ARIA Live Regions
6. Accessibility in Design Systems
7. Remediation Prioritization and Tracking
8. Continuous Accessibility Monitoring
9. FAQ
10. Conclusion

1. The Shift-Left Accessibility Approach

The most efficient time to fix accessibility issues is before they are committed to code. Post-development accessibility audits catch issues, but fixing them requires reworking design systems, component libraries, and code that was built without accessibility in mind. Shift-left accessibility integrates review into the design and development workflow.

Design Review with Claude Prompt: “Review the following wireframe or design specification for accessibility before it goes to development: [describe or paste design]. Evaluate: whether all interactive elements have visible focus indicators, whether color contrast is sufficient (flag any areas that look borderline), whether touch targets are appropriately sized (minimum 44x44 CSS pixels for mobile), whether the heading structure creates a logical outline, and whether form fields have visible labels. Flag any issues that should be corrected before development begins.”

Development Code Review Prompt: “As part of a pre-merge accessibility review, evaluate the following code for WCAG compliance: [paste code]. Check: semantic HTML correctness, ARIA attribute accuracy, keyboard interaction support, focus management logic, form label associations, and dynamic content accessibility. Provide a severity rating (critical/major/minor) for each issue found and specific remediation guidance.”

User Story Accessibility Criteria Prompt: “Generate accessibility acceptance criteria for a user story involving [describe feature — e.g., a new checkout flow with multiple form steps]. Include: the WCAG success criteria that apply to this type of feature, specific testable criteria that a developer or QA analyst can verify, and suggested automated testing coverage for this feature.”

2. Claude for WCAG 2.2 Compliance

WCAG 2.2 introduced several new success criteria that represent compliance gaps for many organizations. Claude can help identify where these new criteria apply and what remediation looks like.

WCAG 2.2 New Criteria Audit Prompt: “WCAG 2.2 added the following new or updated success criteria: 2.4.11 Focus Not Obscured (Minimum), 2.4.12 Focus Not Obscured (Enhanced), 2.4.13 Focus Appearance, 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum). For our website [describe], identify where each of these new criteria likely applies and what violations we should be looking for. For each: explain what the criterion requires, what our current implementation likely violates, and how to fix it.”

Focus Management Audit Prompt: “Review our [describe page or application] for focus management issues. Check: modal dialogs trap focus correctly and return focus to the triggering element on close, custom dropdowns/menus manage focus logically during keyboard navigation, single-page application route changes manage focus appropriately (usually moving focus to the main content area), and any custom scroll behavior preserves keyboard focus position. Identify specific focus management violations and remediation approaches.”

Target Size and Touch Target Audit Prompt: “Our [website/application] targets [describe primary device — desktop users, mobile users, or both]. WCAG 2.2 requires a minimum touch target size of 24x24 CSS pixels (Level AA) and 44x44 pixels (Level AAA for many cases). Review our [describe interface] for touch target issues. Identify: any interactive elements below the minimum size threshold, any elements that are too close together (within 4px) which makes touch selection difficult, and specific remediation for each issue.”

3. Component-Level Accessibility Review

Individual UI components are the building blocks of accessible interfaces. Reviewing components in isolation before they are assembled into pages is the most efficient accessibility review approach.

Modal and Dialog Accessibility Prompt: “Evaluate the following modal/dialog implementation for WCAG compliance. Check: role=“dialog” or role=“alertdialog” is used correctly, aria-modal=“true” is present, the dialog has an accessible name (aria-labelledby pointing to the title), focus is trapped within the dialog while open, focus returns to the triggering element when the dialog closes, pressing Escape closes the dialog, and the background content is inert (not reachable by Tab while the dialog is open).”

[paste modal HTML/JSX]

Carousel and Tab Component Review Prompt: “Evaluate our [carousel/tab component] for accessibility. For carousels: each slide has a meaningful accessible name, previous/next controls are properly labeled, slide indicators are keyboard accessible, auto-playing carousels can be paused, keyboard navigation follows expected patterns. For tabs: tablist/tab/tabpanel roles are correctly applied, tab order follows the visual order, aria-selected indicates the active tab, tab content is properly associated with its tab panel.”

Data Table Accessibility Review Prompt: “Review the following data table implementation for accessibility: [paste table HTML]. Check: tables used for layout are marked with role=“presentation”, data tables have proper th scope attributes, complex tables with merged cells have proper id/headers associations, tables have caption or title, and sortable columns are keyboard accessible with aria-sort attributes.”

4. Page Hierarchy and Navigation Accessibility

Individual components assembled into pages create new accessibility challenges around heading structure, link navigation, and landmark regions.

Site-Wide Heading Structure Review Prompt: “Here is the heading structure of our [describe site section or page type]: [describe heading hierarchy — e.g., Home: H1 site name, H2 main navigation, H2 featured content, H3 article titles]. Evaluate: whether there is exactly one H1 per page, whether heading levels are skipped anywhere, whether headings create a logical outline that screen reader users can navigate, and whether headings describe their following content accurately.”

Skip Navigation Link Review Prompt: “Our [describe site] currently [has/does not have] a skip navigation link. Evaluate whether we need one based on our site structure: a skip link is essential if users must navigate through repetitive navigation to reach main content, particularly for keyboard users. If we need one: where should it appear in the DOM, what should it link to, should it be visible on focus or always visible for accessibility, and how should it be styled?”

Landmark Region Review Prompt: “Review our site’s landmark structure: [describe or paste HTML outline]. Identify: whether we use HTML5 semantic elements (header, nav, main, footer, aside) correctly, whether we have appropriate role attributes where HTML5 elements are not sufficient, whether there are any redundant landmarks (e.g., multiple nav elements that should be distinguished with aria-label), and whether all page content is contained within a landmark.”

5. Dynamic Content and ARIA Live Regions

Dynamic content updates — notifications, form validation, loading states — are a common source of accessibility failures because screen readers need to be explicitly told about changes.

ARIA Live Region Audit Prompt: “Review our [describe application or page] for dynamic content updates. Identify: any content that changes without a page reload (notifications, form validation messages, loading indicators, content refreshes), whether each dynamic update uses the appropriate ARIA live region (aria-live=“polite” for non-urgent updates, aria-live=“assertive” only for urgent time-sensitive updates), whether the live region is present in the DOM before the content that will populate it, and whether we have any instances of assertive announcements that are not truly urgent (which desensitizes users to assertive announcements).”

Focus Changes After Dynamic Content Prompt: “Our [describe application] has the following dynamic content patterns: [describe — e.g., form submission shows success message, item deletion removes the item and focuses the next item]. Evaluate each pattern for accessibility: does focus move appropriately when content changes? Is focus moved to a logical place (not just somewhere arbitrary)? Does focus moving surprise or disorient users? Is focus returned appropriately when a dynamic section is dismissed?”

Loading State Accessibility Prompt: “Generate accessible loading state guidance for [describe context — e.g., a search results page that loads dynamically, a form that shows a spinner during submission]. Include: how to announce loading state to screen readers using ARIA live regions, how to provide meaningful progress information (not just ‘loading…’), how to handle the case where loading takes longer than expected, and what the accessible fallback is if JavaScript fails.”

6. Accessibility in Design Systems

Organizations with design systems have a multiplier effect on accessibility — fixing an accessibility issue in the design system fixes it everywhere the component is used.

Design System Component Audit Prompt: “Audit the following [design system component name] for accessibility: [paste component code or describe]. Check against WCAG 2.2 Level AA requirements: [list the specific WCAG criteria that apply to this component type]. Identify: any current violations, any variants or states (disabled, error, loading) that have additional accessibility concerns, and recommended remediation that should be applied to the design system component so all usages benefit.”

Accessibility Token Guidance Prompt: “Our design system uses color tokens [describe token structure]. Generate guidance for ensuring our color system meets WCAG contrast requirements: what minimum contrast ratios our tokens must satisfy for normal text (4.5:1) and large text (3:1), how to document contrast ratios for each token combination, what automated tools can verify contrast compliance in our design system, and how to handle the case where brand colors cannot meet contrast requirements.”

7. Remediation Prioritization and Tracking

Accessibility remediation is most effective when prioritized by a framework that accounts for impact, effort, and legal risk.

Risk-Based Remediation Prioritization Prompt: “We have identified the following accessibility issues across our site: [list issues with page/component and WCAG criterion violated]. Prioritize remediation using this framework: Priority 1 (fix within 2 weeks) — WCAG Level A violations, issues affecting the largest user populations with disabilities, issues on primary conversion pages. Priority 2 (fix within 60 days) — Level AA violations on secondary pages, component-level fixes that require design system updates. Priority 3 (fix within 90 days) — Level AA violations on low-traffic pages, Level AAA violations on important pages.”

Remediation Effort Breakdown Prompt: “For the following accessibility issues: [list], estimate remediation effort and categorize by fix type. Fix types: content-only (no developer needed — copy changes, alt text), CSS/styling (designer or front-end dev can fix), JavaScript interaction (developer needed, requires interaction logic review), structural HTML (developer needed, requires component restructuring). For each fix, provide: estimated hours, required skill, and whether this fix should be applied to a design system component rather than a single page.”

8. Continuous Accessibility Monitoring

Accessibility is not a one-time project but an ongoing commitment. Building accessibility monitoring into your development workflow prevents new issues from accumulating.

CI/CD Accessibility Integration Prompt: “We use [describe CI/CD system and stack — e.g., GitHub Actions with axe-core]. Generate a CI/CD accessibility testing workflow that: runs automated accessibility checks on every pull request, fails the build when critical or major accessibility issues are detected, generates an accessibility report as a pull request comment, and tracks accessibility debt over time so we can see if our accessibility health is improving or degrading.”

Accessibility Regression Testing Prompt: “We fixed the following accessibility issues: [list]. Generate a regression test plan for these fixes: specific manual test steps that verify each fix, the assistive technology and browser combinations that should be tested, what to do if the fix introduced a new issue, and how to add automated checks to prevent these issues from reoccurring.”

FAQ

How does WCAG 2.2 differ from 2.1 in ways that affect our audit? WCAG 2.2 introduced new requirements around focus visibility (stronger requirements for focus indicators), target size (minimum touch target dimensions), and user input (alternatives for dragging movements). Most organizations have the largest gap in focus appearance requirements, where many custom components have focus indicators that are visually subtle but technically non-compliant.

What is the fastest way to establish an accessibility baseline? Run automated accessibility scans across your top 10 pages by traffic, feed the results into Claude for interpretation and prioritization, fix the critical and major issues within 30 days, then establish a CI/CD-integrated automated testing workflow to prevent regressions.

How do we handle accessibility in third-party embedded content? Third-party embeds (video players, chat widgets, payment flows) are often significant accessibility gaps because you do not control their code. Use aria-label to describe the embed’s purpose, ensure the embed does not trap focus inappropriately, and document the limitations of third-party content in your accessibility statement.

What assistive technology combinations should we test with? Minimum: NVDA on Windows with Firefox or Chrome, VoiceOver on macOS with Safari, and VoiceOver on iOS with Safari. If you serve enterprise users, also test with JAWS on Windows. Test with both keyboard-only navigation and screen reader navigation.

Conclusion

Claude is a powerful tool for shifting accessibility left in the development process — catching issues at design review, code review, and component development stages rather than after deployment. The key is integrating accessibility review into existing workflows rather than treating it as a separate audit project.

Your next step is to identify your highest-traffic page, run an automated accessibility scan, feed the results to Claude with the prioritization prompt in this guide, and commit to fixing your Priority 1 issues within two weeks.