How GitHub Built an AI Workflow That Actually Fixes Accessibility

TL;DR

• GitHub built an event-driven accessibility feedback system using GitHub Actions, Copilot, and Models API that reduced resolution time by 62%
• Custom instructions let accessibility experts update AI behavior through pull requests—no ML training required
• 89% of issues now close within 90 days, up from 21% a year ago
• The system proves AI works best when it handles triage while humans focus on fixing code

The Big Picture

Accessibility bugs are organizational nightmares. A screen reader issue touches navigation, auth, and settings. A keyboard trap lives in a shared component used across dozens of pages. A contrast problem affects every surface using the same design token. No single team owns these problems, but every one blocks a real person from using your product.

For years at GitHub, accessibility feedback had nowhere to go. Reports scattered across backlogs. Bugs lingered without owners. Users followed up to silence. The classic "we'll fix it in phase two" promise that never ships.

GitHub's solution wasn't another audit tool or compliance dashboard. They built an event-driven workflow using GitHub Actions, Copilot, and the Models API that ensures every accessibility report becomes a tracked, prioritized issue with a clear owner. The system reduced average resolution time from 118 days to 45 days. Critical sev1 issues dropped 50%. Issues resolved within 30 days increased 1,150% year-over-year.

The architecture is surprisingly straightforward—and you can build something similar for your own repositories today. Here's how they did it.

How It Works

The system follows an event-driven pattern where each step triggers a GitHub Action. Feedback flows through seven stages: intake, Copilot analysis, submitter review, accessibility team review, audit linking, user follow-up, and continuous improvement.

It starts with centralized intake. 90% of accessibility feedback now flows through GitHub's public accessibility discussion board. When a report needs internal action, a team member creates a tracking issue using a custom template. That creation event triggers two Actions: one engages Copilot for analysis, another adds the issue to a project board for visibility.

The Copilot analysis step is where things get interesting. A GitHub Action calls the Models API with stored prompts developed by accessibility subject matter experts. These prompts live in .github/copilot-instructions.md files that reference internal accessibility policies, component libraries, and WCAG documentation. When standards evolve, the team updates the markdown via pull request. The AI's behavior changes immediately—no retraining pipeline, no ML expertise required.

Copilot populates roughly 80% of the issue's metadata automatically: issue type, user segment, affected components, WCAG success criteria, severity level (sev1 through sev4), impacted user groups, and recommended team assignment. It posts a comment with a summary, suggested WCAG violations, and a checklist of accessibility tests. A second Action parses that comment, applies labels, updates project board status, and assigns the issue to the submitter.

The submitter review layer prevents AI hallucinations from becoming action items. Community managers, support agents, and sales reps—not accessibility experts—use Copilot's checklist to replicate the problem. Questions like "Can you navigate using only a keyboard?" include plain-language instructions and tool links. If they can't reproduce the issue, they reach out to the user for more details. If new information arrives, they re-run the Copilot analysis by manually triggering the Action or removing and re-adding a label.

Once verified, the issue moves to the accessibility team—engineers, designers, champions, testing vendors. They validate Copilot's severity level and WCAG mapping, logging corrections that feed back into prompt refinement. They determine the resolution path: provide documentation directly, create a pull request, or assign to a service team. An Action reassigns the issue to the submitter, who communicates the plan to the user.

The audit linking step connects user feedback to formal internal audits. Roughly 75-80% of reported issues correspond to known problems. Instead of duplicates, the team adds a customer-reported label to the existing audit issue, bumping priority based on real-world impact. If the feedback reveals something new, they create a new audit issue and link it.

Closing the loop is non-negotiable. When a fix ships, the submitter asks the user to test it. If it works, the issue closes. If not, the process loops back to accessibility team review. Issues don't close until users confirm the fix works for them. Because most issues originate from the public discussion board, confirmations are posted there for everyone to see.

The continuous improvement loop is built into the workflow itself. Every Copilot analysis comment includes a link to report inaccuracies. Those reports become pull requests to the custom instruction files. A separate Action scans the internal accessibility guide repository weekly and auto-updates Copilot's instructions. Quarterly reviews track accuracy metrics, resolution times, WCAG failure patterns, and feedback volume trends.

What This Changes For Developers

The architecture proves you don't need a massive ML team to make AI useful. GitHub's accessibility team built this largely by hand starting mid-2024. Today, tools like GitHub Actions and Agentic Workflows let you create similar systems using natural language—meaning you could build this in a fraction of the time.

The stored prompt approach is the key insight. Fine-tuning models requires specialized knowledge and infrastructure. Stored prompts let anyone on the team update AI behavior through a pull request. When your accessibility standards change, you update a markdown file. The AI adapts on the next run, not the next training cycle.

The human-in-the-loop design matters just as much. AI handles triage and formatting—the repetitive work that bogs down teams. Humans verify reproduction, validate severity, determine resolution paths, and confirm fixes with users. The system freed up 70% of manual administrative time, letting the team focus on writing more inclusive code instead of shuffling tickets.

Real-world impact shows in user responses. One user named James reported that the GitHub Copilot CLI was inaccessible—decorative formatting created screen reader noise, interactive elements were impossible to navigate. A team member created a tracking issue. Copilot analyzed it within moments, mapping James's description to technical concepts and providing reproduction steps. The team realized they'd already shipped accessible CLI updates earlier that year. They replied immediately with the --screen-reader mode flag. James's response: "Thanks for pointing out the –screen-reader mode, which I think will help massively."

Another user wrote: "This may not be very professional but I literally just screamed! This fix has actually made my day… Before this I was getting my wife to manage the GitHub issues but now I can actually navigate them by myself! It means a lot that I can now be a bit more independent so thank you again."

That independence is the point. Every workflow, every automation, every review exists so moments like these become the expectation, not the exception.

Try It Yourself

You can build a version of this system for your own repositories today. Start with the foundation:

Create an issue template for accessibility feedback. GitHub's issue template documentation shows how to standardize information collection. Include fields for user impact, affected components, and reproduction steps.

Add a .github/copilot-instructions.md file with your team's accessibility standards. Reference your component library, WCAG success criteria you prioritize, and internal documentation. GitHub's guide on optimizing Copilot custom instructions for accessibility provides detailed examples.

Set up a GitHub Action that triggers on issue creation. Use the Models API to analyze the report and post a comment with triage recommendations. A second Action can parse that comment and apply labels, update project boards, or assign reviewers.

Build in feedback loops. Include a link in every AI-generated comment for reporting inaccuracies. Those reports should feed directly into updates to your custom instructions.

If you maintain an open-source project, this approach scales down beautifully. Even a simple Action that auto-labels accessibility issues and adds them to a project board creates visibility. The key is making accessibility feedback visible and actionable, not letting it disappear into a backlog.

The Bottom Line

Use this approach if you're drowning in accessibility feedback that crosses team boundaries, if you need to scale accessibility expertise across non-expert contributors, or if you want to prove to leadership that accessibility investment produces measurable outcomes. Skip it if you don't have the organizational buy-in to close the loop with users—the system only works if you actually follow through on fixes.

The real risk isn't that AI will replace accessibility experts. It's that teams will use AI as an excuse to skip the human foundation—design annotations, code scanners, accessibility champions, testing with people with disabilities. Those aren't replaced by AI. They're what make AI-assisted workflows effective. Without that foundation, AI is just a faster way to miss the point.

The opportunity is building systems where AI handles the repetitive work so humans can focus on what matters: writing more inclusive code and closing the loop with users who take the time to report barriers. GitHub's system proves that when you get the architecture right, accessibility feedback doesn't disappear into a backlog. It flows continuously through the right channels until it's resolved.

If you hit an accessibility barrier while using GitHub, share your feedback. It won't disappear. They're listening—and now they have the system to follow through.

Source: GitHub Blog