Building a general-purpose accessibility agent—and what we learned in the process (opens in new tab)

GitHub is piloting a general-purpose accessibility agent that answers accessibility questions and automatically fixes straightforward issues in front-end code. The agent has reviewed 3,535 pull requests and resolved 68% of identified issues, especially problems involving structure, control names, status messages, text alternatives, and keyboard focus. GitHub’s experience shows that an accessibility agent is most effective as an augmentation of human expertise, supported by a strong foundation of manually documented accessibility work.

Goals and Results

• The agent serves two purposes:
  • Provide just-in-time accessibility guidance through GitHub Copilot CLI and VS Code.
  • Detect and automatically remediate simple, objective accessibility issues before production.
• It evaluates pull requests that modify front-end code.
• Its five most common issue categories are:
  • Making structure and relationships understandable to assistive technologies.
  • Giving interactive controls clear, concise names.
  • Ensuring users receive important status announcements.
  • Providing text alternatives for non-text content.
  • Maintaining a logical keyboard focus order.
• Example fixes can identify mismatches between visual order and screen-reader reading order, then suggest code changes that developers can commit directly.

An Augmenting, Not Universal, Tool

• GitHub frames accessibility through the social model of disability: barriers are often created by how digital environments are designed and built.
• The agent is intended to help engineers remove those barriers, not “solve” accessibility independently.
• It is not a silver bullet capable of handling every accessibility scenario.
• Clearly limiting its responsibility helped GitHub launch the experiment more quickly and gain broader internal support.

Why Manual Accessibility Work Matters

• New and upcoming regulations, including the European Accessibility Act and the Americans with Disabilities Act’s planned WCAG 2.1 AA requirements, increase the importance of accessibility investment.
• Organizations without established processes for manually identifying and fixing accessibility problems will be at a disadvantage.
• GitHub already had a mature issue-management process containing:
  • Structured problem reports.
  • Reproduction steps.
  • Severity, service-area, and WCAG metadata.
  • Links to fixing pull requests.
  • Acceptance criteria.
• Centralizing these issues in one repository made the collection a valuable reference corpus for the agent.

Using Historical Issues as Training Material

• The agent examines past accessibility issues and related pull requests to find applicable code and language patterns.
• LLMs’ fuzzy matching can be useful here because it helps connect new problems with similar historical examples.
• Generic instructions such as “follow accessibility best practices” are insufficient.
• LLMs often reproduce accessibility antipatterns because their training data contains decades of inaccessible code.
• Manually cataloged issues and organization-specific fixes provide contextual examples that are more useful than short, generic accessibility checklists.

GitHub’s experience suggests that teams should first build reliable human processes for reporting and remediating accessibility issues. Once that structured knowledge exists, an agent can help apply it consistently and efficiently—while remaining a complement to, rather than a replacement for, accessibility expertise.