I’ve seen a lot of companies talk about using artificial intelligence to improve their products. Most of it is noise. But GitHub’s accessibility feedback workflow is different, and not because it’s particularly clever or uses some cutting-edge model. It’s different because it solves a real problem that happens to be perfectly suited for AI: turning scattered user complaints into trackable, actionable engineering work.
The problem they faced was straightforward but messy. Accessibility bugs don’t belong to any single team. A screen reader user reports a broken workflow that touches navigation, auth, and settings. Who owns that? Nobody, which means it falls through the cracks. For years, that’s exactly what happened at GitHub. Feedback scattered across backlogs, bugs lingered without owners, users followed up to silence.
What interests me here isn’t that they built an AI system. It’s that they built the boring infrastructure first. They centralized reports, created templates, triaged years of backlog. Only then did they ask how AI could help. That sequencing matters more than the technology itself.
The Architecture That Actually Makes Sense
The workflow they built is event-driven, which sounds fancy but really just means each step triggers the next one automatically. When someone creates an accessibility issue, a GitHub Action fires. It calls the GitHub Models API, which runs GitHub Copilot against a custom prompt. That prompt was written by accessibility experts and points to internal documentation about WCAG compliance.
GitHub Copilot fills in about 80% of the metadata automatically. Issue type, affected components, severity level, user segment. It generates a checklist for the person who submitted the issue, walking them through how to replicate the problem even if they have zero accessibility expertise. Then it posts all of this as a comment, which triggers another Action that applies labels and updates a project board.
What I like about this is that they didn’t fine-tune a model. They used stored prompts that anyone can update via pull request. When their accessibility standards change, they update a markdown file. The AI’s behavior changes with the next run. No retraining pipeline, no ML specialists required.
The human review happens in two layers. First, the submitter tries to replicate the issue using the checklist GitHub Copilot generated. If they can’t reproduce it, they go back to the user for more details. If they can, they mark it as reviewed, which kicks it over to the accessibility team.
That team validates everything. They check the severity level, the WCAG mapping, the category labels. When GitHub Copilot gets something wrong, they log it and use those corrections to refine the prompt files. Over time, the system gets smarter because they’re feeding real-world corrections back into it.
Why This Works When Most AI Workflows Don’t
A year ago, nearly half of GitHub’s accessibility feedback sat unresolved for over 300 days. Now that backlog is gone. Median resolution time dropped from 60 days to 8. That’s not because AI is magic. It’s because they built a system where AI handles the repetitive work so humans can focus on the parts that actually matter.
The most important step in their entire workflow isn’t automated at all. It’s the follow-up with users. When a fix ships, the submitter goes back to the person who reported the issue and asks them to test it. They don’t close the tracking issue until the user confirms it works. If it doesn’t, the loop starts over.
That’s the part most companies skip. They treat feedback as a one-way flow. User reports bug, team fixes bug, issue closed. But accessibility isn’t like that. You can’t know if you fixed a screen reader issue unless a screen reader user tells you it’s fixed. GitHub gets this, and their workflow enforces it.
There’s a user named James who emailed them about the GitHub Copilot CLI being inaccessible. Decorative formatting created noise for screen readers. Interactive elements were impossible to navigate. A team member created a tracking issue, GitHub Copilot analyzed it, and they realized they’d already shipped a fix earlier in the year. James just didn’t know about it. They replied immediately, pointed him to the screen reader mode, and he was back to work. Hours, not months.
The Infrastructure No One Wants To Build
What makes this system work isn’t the AI. It’s the foundation they built before adding AI. Issue templates that standardize how information gets collected. A discussion board where 90% of feedback flows through a single channel. Automated weekly reports that surface which WCAG criteria fail most often. A separate audit system that tracks known issues so they don’t create duplicates.
They also built a feedback loop into the workflow itself. Every comment GitHub Copilot generates includes a link to report inaccuracies. When someone spots a mistake, they open an issue describing what went wrong. That correction becomes a pull request to the prompt files. The system improves continuously because they designed it to learn from its mistakes.
Another GitHub Action scans their internal accessibility guide repository weekly and updates GitHub Copilot’s custom instructions automatically. As their standards evolve, the AI stays in sync without manual intervention.
This is the kind of infrastructure work that doesn’t make for good conference talks. It’s not flashy. But it’s the difference between an AI system that actually helps and one that generates plausible-sounding nonsense.
What This Means For The Rest Of Us
If you maintain any kind of open source project, you can build a simpler version of this today. Start with an issue template for accessibility. Add a .github/copilot-instructions.md file with your team’s standards. Let AI handle triage and formatting so you can focus on writing more inclusive code.
The bigger takeaway is that AI works best when it amplifies human voices instead of replacing them. GitHub’s system doesn’t decide what to fix. It doesn’t close issues on its own. It doesn’t make judgment calls about severity. It does the boring work of structuring feedback, generating checklists, and keeping everyone aligned so humans can make informed decisions quickly.
That’s the pattern worth copying. Not the specific tools or the exact workflow, but the philosophy. Use AI to handle repetition. Keep humans in the loop for judgment. Build feedback mechanisms so the system gets smarter over time. Don’t automate the parts that require empathy or lived experience.
GitHub could have built a fully automated system that triages and routes issues without human review. They chose not to, and that choice is why their workflow actually serves users instead of just making dashboards look better.