Can AI Write Accessible Code?

import { useEffect, useRef } from 'react';

export function Modal({ isOpen, onClose, title, children }) {
  const dialogRef = useRef(null);
  const triggerRef = useRef(null);

  useEffect(() => {
    const dialog = dialogRef.current;
    if (!dialog) return;
    if (isOpen && !dialog.open) {
      triggerRef.current = document.activeElement;
      dialog.showModal();            
    } else if (!isOpen && dialog.open) {
      dialog.close();
    }
  }, [isOpen]);

  const handleClose = () => {
    onClose();
    triggerRef.current?.focus();     
  };

  return (
    <dialog ref={dialogRef} aria-labelledby="modal-title" onClose={handleClose}>
      <h2 id="modal-title">{title}h2>
      {children}
      <button type="button" onClick={handleClose}>Closebutton>
    dialog>
  );
}

The onClose event fires for both the Close button and the Escape key, so focus is always restored. If your team must support a custom modal instead, test it against the ARIA Authoring Practices Guide dialog pattern with a real screen reader before shipping.

Audit 4: Sticky Headers, Small Targets and Drag-and-Drop

This audit groups three of the new WCAG 2.2 AA criteria, because they share one trait: they are about layout and interaction rather than markup, so they are almost invisible in a code suggestion.

2.4.11 Focus Not Obscured (Minimum)

Ask Copilot for // sticky header with nav and you’ll get a correct-looking position: sticky header. Nothing in that suggestion is wrong on its own. The failure appears later, when a keyboard user tabs down the page and each focused link scrolls underneath the header. The fix is one line of CSS that Copilot almost never offers unprompted:

.site-header {
  position: sticky;
  top: 0;
  height: 72px;
  z-index: 10;
}


html {
  scroll-padding-top: 88px; 
}

The same applies to cookie banners and chat widgets fixed to the bottom of the viewport; use scroll-padding-bottom for those.

2.5.8 Target Size (Minimum)

Pagination, tag chips and table row actions are frequent offenders. Copilot tends to suggest compact styles copied from dense dashboard UIs, such as padding: 2px 6px with a 12px font. Set a minimum on the interactive element, not on the icon inside it:

.pagination a,
.chip-remove,
.row-action {
  min-width: 24px;
  min-height: 24px;
  display: inline-flex;
  align-items: center;
  justify-content: center;
}

2.5.7 Dragging Movements

Ask for // sortable list with drag and drop and Copilot will reliably produce a working HTML5 drag-and-drop or library-based list. It will almost never provide a non-dragging alternative. Users with tremors, switch devices or head pointers need one. The simplest fix is a pair of move buttons per item:

function SortableItem({ item, index, total, onMove }) {
  return (
    <li draggable onDragStart={ undefined}>
      <span>{item.label}span>
      <button type="button" onClick={() => onMove(index, index - 1)}
              disabled={index === 0} aria-label={`Move ${item.label} up`}>↑button>
      <button type="button" onClick={() => onMove(index, index + 1)}
              disabled={index === total - 1} aria-label={`Move ${item.label} down`}>↓button>
    li>
  );
}

Pair this with a polite live region that announces “Blue sneakers moved to position 2 of 5” so screen reader users get confirmation of the change.

Audit 5: The Login Form

3.3.8 Accessible Authentication (Minimum) is the newest criterion most teams have not yet absorbed, and AI assistants reflect that. The neutral prompt // login form with password and one-time code often produces something like this:

<form onSubmit={login}>
  <input type="text" placeholder="Username" onChange={...} />
  <input type="password" placeholder="Password" onPaste={e => e.preventDefault()} onChange={...} />
  <div className="otp">
    {[0, 1, 2, 3, 4, 5].map(i => (
      <input key={i} maxLength={1} onChange={e => focusNext(i, e)} />
    ))}
  div>
  <button>Sign inbutton>
form>

What fails:

• 3.3.8 Accessible Authentication (Minimum) (AA): blocking paste on the password field forces users to recall and retype it, which defeats password managers. That is exactly the cognitive function test the criterion prohibits.
• 1.3.5 Identify Input Purpose (AA): no autocomplete values, so browsers cannot fill credentials or one-time codes.
• 1.3.1 and 4.1.2: six unlabeled single-character inputs announce as six blank edit fields, and the automatic focus jumping disorients screen reader users.

The corrected version is shorter, not longer:

<form onSubmit={login}>
  <label htmlFor="username">Email or usernamelabel>
  <input id="username" name="username" autoComplete="username" />

  <label htmlFor="password">Passwordlabel>
  <input id="password" name="password" type="password" autoComplete="current-password" />

  <label htmlFor="otp">6-digit code from your authenticator applabel>
  <input
    id="otp"
    name="otp"
    inputMode="numeric"
    autoComplete="one-time-code"
    pattern="[0-9]{6}"
    maxLength={6}
  />

  <button type="submit">Sign inbutton>
form>

A single code field lets users paste the full code and lets mobile browsers offer it from SMS automatically. If your design requires segmented boxes, keep them as a visual treatment over a single real input. Better still, offer passkeys or email magic links, which remove the cognitive test entirely.

The Scorecard

Across the five components, an accessibility-aware prompt reliably fixed markup-level issues but left the new WCAG 2.2 criteria mostly unaddressed.

Three patterns stand out:

1. Copilot mirrors its context. In a codebase full of
   , it suggests more of them. In a codebase with a well-built accessible component library, its suggestions improve noticeably. Your existing code is your strongest prompt.

2. Intent helps markup, not behavior. Mentioning accessibility gets you labels, roles and aria-* attributes. It does not get you focus management, live announcements or keyboard alternatives unless you name them.
3. WCAG 2.2 is a blind spot. Focus Not Obscured, Target Size, Dragging Movements and Accessible Authentication rarely appear unless the prompt names the criterion directly. Even then, the fix is often partial.

The verdict: AI can write accessible code, but it cannot be trusted to do so on its own. It is a fast junior developer with uneven accessibility training, and it needs the same guardrails you’d give one.

Making Copilot Write Better Code by Default

You don’t need to write perfect prompts every time. Put three layers of guardrails around the assistant instead: instructions it reads, linting at the keyboard, and tests in CI.

Layer 1: Repository custom instructions

Copilot reads a .github/copilot-instructions.md file in your repository and applies it to chat and agent requests. Use it to encode your accessibility standards once, for the whole team:

# Accessibility requirements (WCAG 2.2 AA)

- Use native HTML elements before ARIA: <button>, <a href>, <dialog>, <label>.
- Never attach click handlers to <div> or <span>.
- Every form input has a visible <label> linked with htmlFor/id. Placeholders are not labels.
- Add autocomplete attributes to personal-data and credential fields.
- Link error messages to inputs with aria-describedby and set aria-invalid.
- Icon-only buttons need aria-label; decorative SVGs get aria-hidden="true".
- Interactive targets are at least 24x24 CSS px (prefer 44x44 on touch).
- Never block paste in password or one-time-code fields.
- Any drag interaction must have a button-based alternative.
- Modals use <dialog>.showModal() and return focus to the trigger on close.
- Sticky or fixed UI must not cover focused elements; set scroll-padding.
- Prefer components from our design system (src/components/a11y) over new ones.

Layer 2: Prompt patterns that work

When you prompt directly, name the behavior, not just the goal. “Make it accessible” is vague. Compare these:

• Weak: // accessible dropdown menu
• Strong: // Disclosure menu: button with aria-expanded, Escape closes and returns focus to button, arrow keys move between items, 24px minimum targets

It also helps to ask Copilot Chat to review its own output against a named criterion, for example: “Review this component against WCAG 2.2 success criteria 2.4.11, 2.5.7 and 2.5.8 and list any failures.” Self-review catches some issues, but treat its answer as a lead to verify, not a verdict.

Layer 3: Linting and CI

Catch what slips through before it merges. eslint-plugin-jsx-a11y flags many markup issues as you type:

{
  "extends": ["plugin:jsx-a11y/strict"]
}

Then run axe against rendered pages in your end-to-end tests with @axe-core/playwright:

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('checkout page meets WCAG 2.2 AA automated checks', async ({ page }) => {
  await page.goto('/checkout');
  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag21aa', 'wcag22aa'])
    .analyze();
  expect(results.violations).toEqual([]);
});

test('focused links are not hidden by the sticky header', async ({ page }) => {
  await page.goto('/checkout');
  for (let i = 0; i < 15; i++) {
    await page.keyboard.press('Tab');
    const focusTop = await page.evaluate(() => document.activeElement.getBoundingClientRect().top);
    const headerBottom = await page.evaluate(
      () => document.querySelector('.site-header').getBoundingClientRect().bottom
    );
    expect(focusTop).toBeGreaterThanOrEqual(headerBottom);
  }
});

The second test shows that some WCAG 2.2 criteria can be checked with a few lines of custom code even when no rule engine covers them. It is a simplified check; elements inside the header itself would need to be excluded in a real suite.

Finally, keep a human in the loop. Add a short accessibility checklist to your pull request template and schedule regular screen reader and keyboard testing. No combination of AI and automation replaces it.

Conclusion

So, can AI write accessible code? Yes, but only as accessible as the context, instructions and checks you surround it with. GitHub Copilot speeds up the markup layer of accessibility, but it consistently misses behavior, focus management and the newer WCAG 2.2 criteria unless someone who understands them is steering.

That makes accessibility expertise more valuable in an AI-assisted team, not less. The developer who knows that a sticky header can hide focus, or that blocking paste breaks password managers, is the one who turns Copilot from a source of accessibility debt into a way to pay it down.

Key takeaways:

• Treat every AI-generated UI component as untested until it passes keyboard, screen reader and automated checks.
• Encode your accessibility rules in .github/copilot-instructions.md so every suggestion starts from the right baseline.
• Prompt for behavior (focus, keyboard, announcements), not just for “accessible”.
• Give extra scrutiny to the WCAG 2.2 criteria: 2.4.11, 2.5.7, 2.5.8, 3.3.7 and 3.3.8.
• Build an accessible component library. Copilot imitates your codebase, so a good one is the best prompt you can write.

Run this audit on your own codebase and share your results. The more teams publish what AI gets right and wrong about accessibility, the faster these tools, and the people using them, will improve.

About the author: Ashok Kumar Yadav is an Accessibility Architect and Senior Software Engineer with more than 20 years of experience in web and mobile accessibility. He is an IEEE Senior Member, a published author on web accessibility, and the creator of Tab Order Visualizer. Connect with him on LinkedIn.