TestParty

Blog

The Hidden Crisis in AI-Generated Web Accessibility: How Better Prompting Can Transform Your Results

Michael Bervell
Michael Bervell
November 29, 2025

You wouldn't ask someone to "make dinner" and expect a perfectly seasoned, restaurant-quality meal. You'd specify ingredients, cooking methods, dietary restrictions, and presentation preferences. Yet when we ask AI to generate accessible HTML, we often use prompts as vague as "make a modal dialog" – and then wonder why the results fail basic accessibility standards.

At TestParty, we've spent countless hours analyzing how AI models handle accessibility tasks, and the recent Microsoft A11y LLM Eval report confirms what we've learned through painful trial and error: the difference between accessible and inaccessible AI-generated code often comes down to prompt engineering, not model capabilities.

The Stark Reality: Current AI Accessibility Performance

The Microsoft evaluation tested leading AI models on their ability to generate accessible HTML components. The results are sobering:

  • GPT-5 Mini leads with only 31% WCAG pass rate
  • Claude Sonnet 4.5 achieved 0% pass rate
  • Most models averaged 5-12 WCAG failures per generated component

But here's the crucial detail: these tests used deliberately minimal prompts. The system prompt was simply:

You are generating a single standalone HTML document. Do NOT wrap output in markdown fences. Include <head> and <body>. Do NOT explain the code, just output it.

This bare-bones instruction set is exactly how many developers interact with AI today – and it's setting us up for failure.

Dissecting the Problem: Three Prompts, Three Opportunities

Let's examine the three test prompts from the evaluation and transform them into accessibility powerhouses.

Prompt 1: The Disclosure Widget

Original prompt:

Generate an HTML file that demonstrates an expand/collapse widget.
Wrap each widget with a div that has an `example` class.
Give the container for controlled content a `details` class.

What's wrong: This prompt focuses entirely on visual structure without mentioning interaction patterns, keyboard navigation, or screen reader announcements. It's like asking an architect to design a building without mentioning it needs to be wheelchair accessible.

Enhanced accessibility-focused prompt:

Generate an accessible expand/collapse disclosure widget following WCAG 2.2 AA standards.

Requirements:
1. Use semantic HTML5 elements where appropriate
2. Implement ARIA attributes following the disclosure pattern:
   - Use button element with aria-expanded="false/true"
   - Connect button to content with aria-controls
   - Ensure controlled content has matching id
3. Keyboard accessibility:
   - Button must be keyboard focusable (tabindex if needed)
   - Space and Enter keys should toggle expansion
   - Focus should be visible with clear outline
4. Screen reader support:
   - Announce state changes
   - Use aria-label or visible text that describes the action
5. Visual implementation:
   - Wrap each widget in div with class="example"
   - Give content container class="details"
   - Include visible focus indicators (outline: 2px solid)

Example structure:
<button aria-expanded="false" aria-controls="content1">
  Show More Details
</button>
<div id="content1" class="details" hidden>
  [Content here]
</div>

Prompt 2: The Modal Dialog

Original prompt:

Create an example of a modal dialog component. It is closed by default, and the button to open it has a `trigger` class.

What's wrong: No mention of focus management, escape key handling, background interaction prevention, or screen reader announcements – all critical for accessible modals.

Enhanced accessibility-focused prompt:

Create a fully accessible modal dialog component meeting WCAG 2.2 AA standards.

Core requirements:
1. Focus management:
   - Trap focus within modal when open
   - Return focus to trigger button when closed
   - First focusable element receives focus on open
2. Keyboard interaction:
   - Escape key closes modal
   - Tab cycles through modal elements only
   - Shift+Tab reverses cycle
3. ARIA implementation:
   - dialog element or role="dialog"
   - aria-modal="true" 
   - aria-labelledby pointing to modal title
   - aria-describedby for modal description if present
4. Screen reader announcements:
   - Announce modal opening
   - Announce modal title and purpose
5. Background interaction:
   - Prevent clicking outside modal
   - Add inert attribute to main content or aria-hidden="true"
6. Visual requirements:
   - Trigger button with class="trigger"
   - Modal hidden by default (display: none or hidden attribute)
   - Visible focus indicators throughout
   - Semi-transparent backdrop to indicate modal state

Include JavaScript for:
- Opening/closing functionality
- Focus trap implementation
- Escape key handler
- Click-outside-to-close with proper event handling

Prompt 3: The Shopping Homepage

Original prompt:

Generate an HTML file for the home page of a shopping website. The home page has several sections of content for popular items, deals, and blog posts.

What's wrong: Zero guidance on semantic structure, navigation patterns, or content organization for assistive technologies.

Enhanced accessibility-focused prompt:

Generate a fully accessible shopping website homepage following WCAG 2.2 AA standards and e-commerce best practices.

Semantic structure:
1. Use HTML5 semantic elements:
   - <header> with site name and navigation
   - <nav> with aria-label="Main navigation"
   - <main> for primary content
   - <section> for each content area with descriptive aria-label
   - <footer> with supplementary links
2. Heading hierarchy:
   - Single <h1> for page title
   - <h2> for major sections (Popular Items, Deals, Blog)
   - <h3> for subsections
   - Never skip heading levels
3. Navigation:
   - Skip link to main content as first focusable element
   - Consistent navigation structure
   - Current page indication with aria-current="page"
4. Product cards must include:
   - Product name as heading or aria-label
   - Price with proper currency formatting
   - Alt text for product images describing the item
   - Buttons with descriptive text (not just "Buy Now")
5. Interactive elements:
   - All links have descriptive text (no "click here")
   - Buttons vs links used appropriately
   - Form inputs have associated labels
   - Error messages connected with aria-describedby
6. Images:
   - Informative images have descriptive alt text
   - Decorative images have empty alt=""
   - Complex images use aria-describedby for long descriptions
7. Color and contrast:
   - Don't rely on color alone for information
   - Include text/icon indicators for sales/deals
   - Ensure 4.5:1 contrast for normal text
   - Ensure 3:1 contrast for large text

Include comments marking major landmarks for screen reader users.

The Science Behind Better Prompting

Research from leading AI labs provides clear guidance on crafting effective prompts. Let's explore the key principles with accessibility-specific applications:

1. Be Explicit About Requirements

Anthropic's research on constitutional AI shows that models perform better when given explicit success criteria. For accessibility, this means specifying WCAG standards, not just asking for "accessible" code.

Instead of: "Make it accessible" Use: "Implement WCAG 2.2 Level AA compliance, specifically addressing criteria 2.1.1 (Keyboard), 2.4.3 (Focus Order), and 4.1.2 (Name, Role, Value)"

2. Provide Structured Templates

OpenAI's prompt engineering guide emphasizes the value of templates. For accessibility, provide ARIA patterns:

Template for accessible form field:
<div class="form-group">
  <label for="[field-id]" id="[label-id]">
    [Label Text]
    <span aria-label="required" class="required">*</span>
  </label>
  <input 
    type="[type]" 
    id="[field-id]"
    aria-labelledby="[label-id]"
    aria-describedby="[error-id] [help-id]"
    aria-required="true"
    aria-invalid="false"
  />
  <span id="[help-id]" class="help-text">[Help text]</span>
  <span id="[error-id]" class="error-message" role="alert" aria-live="polite"></span>
</div>

3. Chain-of-Thought Prompting

Google's research on chain-of-thought prompting demonstrates that asking models to explain their reasoning improves accuracy. Apply this to accessibility:

Before generating the HTML:
1. List all user interaction points
2. Identify keyboard navigation requirements
3. Determine necessary ARIA attributes
4. Plan the focus management strategy
5. Then generate code implementing these decisions

4. Few-Shot Learning

Providing examples dramatically improves output quality. Include both correct and incorrect examples:

CORRECT accordion pattern:
<button aria-expanded="false" aria-controls="panel1">Section 1</button>
<div id="panel1" hidden>Content</div>

INCORRECT accordion pattern (explain why):
<div onclick="toggle()">Section 1</div>  // Not keyboard accessible
<div class="content">Content</div>       // No semantic relationship

Your Practical Guide to Accessibility Prompting

Here's your copy-and-paste toolkit for generating accessible components:

The Universal Accessibility Prompt Prefix

Start every HTML generation request with:

Generate fully accessible HTML following WCAG 2.2 Level AA standards.
Ensure:
- Keyboard navigation for all interactive elements
- Screen reader compatibility with proper ARIA
- Visible focus indicators (outline: 2px solid #0066cc)
- Semantic HTML5 elements used appropriately
- Color contrast ratios meet standards (4.5:1 normal, 3:1 large text)

Component-Specific Templates

For Navigation Menus:

Create an accessible navigation menu with:
- <nav role="navigation" aria-label="[Purpose]">
- Keyboard arrow key navigation between items
- aria-current="page" for current page
- Submenu pattern: aria-haspopup="true" aria-expanded="false/true"
- Escape key closes submenus
- Skip link before navigation: <a href="#main" class="skip-link">Skip to main content</a>

For Forms:

Build an accessible form with:
- Labels connected via for/id attributes
- Required fields: aria-required="true" and visual indicator
- Error messages: role="alert" aria-live="polite"
- Fieldsets for grouped inputs with <legend>
- Instructions linked with aria-describedby
- Submit button as <button type="submit"> not <input>

For Data Tables:

Create an accessible data table with:
- <caption> describing table purpose
- <thead>, <tbody>, <tfoot> structure
- <th scope="col"> for column headers
- <th scope="row"> for row headers
- For complex tables: headers attribute linking cells to headers
- Summary attribute or aria-describedby for complex relationships

For Carousels:

Design an accessible carousel with:
- Pause/play button with aria-label
- Previous/next buttons with descriptive labels
- aria-live="polite" region for updates
- Keyboard controls: arrow keys for navigation
- Tab panel pattern: role="tablist", role="tab", role="tabpanel"
- Auto-rotation pauses on hover and focus
- Slide indicators with aria-label="Slide X of Y"

Testing Checklist Prompt

After generation, add:

Now validate the generated HTML against:
1. Can all functionality be accessed via keyboard alone?
2. Do all images have appropriate alt text?
3. Is the heading hierarchy logical (h1 → h2 → h3)?
4. Are all form inputs labeled?
5. Do error messages clearly identify the problem?
6. Is focus order logical and visible?
7. Are ARIA attributes used correctly?
8. Would a screen reader user understand the content flow?

Advanced Techniques: Multi-Stage Prompting

For complex components, break the process into stages:

Stage 1: Structure

First, create the semantic HTML structure for [component].
Focus only on proper element choice and document outline.

Stage 2: ARIA Enhancement

Now add appropriate ARIA attributes to the structure.
Include: roles, states, properties, and live regions.

Stage 3: Interaction

Add JavaScript for keyboard navigation and focus management.
Include: tab order, arrow keys, escape key, enter/space activation.

Stage 4: Visual Design

Finally, add CSS ensuring:
- Focus indicators (outline, not just color change)
- Sufficient color contrast
- Responsive design maintaining accessibility

Real-World Testing Integration

Combine AI generation with testing prompts:

After generating the component:
1. Create axe-core test cases for this component
2. Write Playwright accessibility tests covering:
   - Keyboard navigation flow
   - Screen reader announcements
   - Focus management
   - ARIA state changes
3. Generate Pa11y test configuration
4. Create manual testing checklist for:
   - Screen reader testing (NVDA, JAWS, VoiceOver)
   - Keyboard-only navigation
   - Browser zoom to 400%
   - Windows High Contrast mode

The Business Case for Better Prompting

At TestParty, we've seen that spending an extra 2-3 minutes crafting a detailed accessibility prompt can save:

  • 10-20 hours of remediation work per component
  • $5,000-15,000 in accessibility consultant fees
  • Potential lawsuits ranging from $10,000 to $100,000+

More importantly, it ensures your digital products are usable by the 1.3 billion people worldwide with disabilities.

Conclusion: Your Prompting Evolution

The gap between 0% and 90% accessibility compliance in AI-generated code isn't about waiting for better models – it's about writing better prompts today. Every prompt is an opportunity to build inclusion into your codebase from the start.

Start with one enhanced prompt from this guide. Test it. Refine it. Share it with your team. Build a library of accessibility-focused prompts that become your standard toolkit.

Remember: AI models are remarkably capable when given clear, specific, and comprehensive instructions. The question isn't whether AI can generate accessible code – it's whether we're asking it the right way.

The tools are in your hands. The templates are ready to copy. The only thing standing between you and accessible AI-generated code is the quality of your next prompt.

Want to validate your AI-generated components? Try TestParty's automated accessibility testing – we catch what manual testing misses, and we're built by developers who understand that great prompting is just the beginning of the accessibility journey.

Stay informed

Accessibility insights delivered
straight to your inbox.

Contact Us

Automate the software work for accessibility compliance, end-to-end.

Empowering businesses with seamless digital accessibility solutions—simple, inclusive, effective.

Book a Demo