10 Lessons from Building a General-Purpose Accessibility Agent

Accessibility is often seen as a tedious checklist item—something developers dread but must grudgingly comply with. But what if we could automate the boring parts, freeing humans to focus on the nuanced, creative decisions? That’s exactly what GitHub set out to explore with their experimental general-purpose accessibility agent. Drawing from eight months of real-world testing across 3,535 pull requests, this article unpacks the top ten insights from the journey.

1. The Rise of Accessibility Agents

GitHub has long embraced agent-based workflows for code creation and editing. Now, they’re piloting an accessibility-specific agent that works inside Copilot CLI and VS Code. The agent isn’t just a static rule-checker; it uses LLMs to understand context and offer just-in-time advice. The goal? Catch common accessibility issues before they ever hit production. This experiment shows how agents can go beyond code generation to enforce inclusive design patterns—without drowning developers in alerts.

2. Two Core Objectives

The agent has two clear missions. First, answer engineers’ accessibility questions on the fly—right in their development environment. Second, automatically detect and fix simple, objective accessibility problems in front-end code before deployment. By splitting these goals, the team could measure success independently. The first goal improves developer education; the second directly removes barriers for users of assistive technology.

3. Real-World Impact: 3,535 Pull Requests Reviewed

Over the trial period, the agent scanned over three thousand pull requests and resolved 68% of the issues it flagged. That’s a high success rate for an experimental tool. The remaining 32% likely required human judgment—things like semantic meaning or design intent. Still, automating even two-thirds of accessibility defects saves countless hours. The agent focuses on objective patterns, which are easier to codify, while leaving subjective assessments to human reviewers.

4. Issue #1: Structural Clarity for Assistive Technologies

The most common problem the agent flagged was unclear page structure. Screen readers depend on landmarks like headers, lists, and regions to navigate. When these are missing or misused, people using assistive tech get lost. The agent alerts engineers to add proper roles, ARIA landmarks, and semantic HTML. This single change can dramatically improve a page’s usability for blind or low-vision users.

5. Issue #2: Naming Interactive Controls Clearly

Interactive elements—buttons, links, form fields—need accessible names. A button that just says “Click here” is meaningless without context. The agent checks that every control has a unique, descriptive label, either through visible text or aria-label attributes. This not only helps screen readers but also supports voice control and switch devices. Clear naming reduces cognitive load for all users.

6. Issue #3: Announcement Awareness

Dynamic content changes (like loading spinners or live region updates) must be announced to assistive technologies. The agent ensures that important updates are properly marked with role="alert" or aria-live. Without this, users might miss critical feedback—like a form submission error or a new message notification. The agent catches these silent failures and suggests concrete fixes.

7. Issue #4: Text Alternatives for Non-Text Content

Images, icons, and other non-text elements require alt text. The agent scans for missing or empty alt attributes and even suggests context-aware descriptions. It also flags decorative images that should be marked with role="presentation" to avoid clutter. By automating this, the agent helps teams meet WCAG success criteria without relying on manual audits.

8. Issue #5: Logical Keyboard Focus Order

Keyboard users expect a logical tab order. When focus jumps randomly or skips important elements, it creates confusion. The agent reviews the DOM order and flags mismatches with visual layout. It also checks that focus indicators are visible and that no element traps the keyboard. This ensures that everyone—including those with motor disabilities—can navigate the interface efficiently.

9. The Mindset: Augmentation, Not Silver Bullet

The team behind the agent embraces the social model of disability: barriers arise from how we design environments, not from the individual. They see the agent as an augment—a tool that helps engineers remove those barriers, not a magic fix. This mindset sets realistic expectations. By deliberately scoping the agent to objective issues, they launched faster and earned broader buy-in from developers who feared overhead.

10. Learnings from the Experiment

The experiment proved that LLM-powered agents can effectively handle routine accessibility checks. Key takeaways: start with objective patterns, integrate into existing workflows (like pull request review), and celebrate wins publicly to build momentum. The 68% resolution rate shows that automation can significantly reduce accessibility debt. Future iterations might tackle more subjective issues or even suggest design changes. For now, the agent proves that inclusive software is also efficient software.

Building an accessibility agent isn’t about replacing human judgment—it’s about giving engineers superpowers. By handling the boring, repetitive checks, the agent frees up time for thoughtful discussions about design. GitHub’s experiment offers a blueprint for other teams: start small, measure everything, and always keep the human in the loop. The result? A more accessible web, one pull request at a time.