Accessibility feedback used to arrive everywhere at once. Support tickets, community forums, social media, direct messages to whoever people could find. Each report was real, and each one landed somewhere different, in a different format, with no way to tell whether it was new or the fortieth report of the same problem. A lot of it went nowhere, which is its own accessibility problem: you can't tell people their feedback matters and then lose it.
The pipeline is the answer to that. Every piece of accessibility feedback now enters through one structured intake, and from there an agentic workflow does the analysis a human triager would do if there were enough humans.
How it works. A custom issue template captures the source, the component, and the barrier the person hit. Creating the issue fires a GitHub Action, which hands the report to the Models API. The model classifies it against WCAG 2.2, scores severity, identifies the affected user segment — screen reader, keyboard-only, low vision — and checks it against internal documentation and the component library to figure out which team owns the code. It writes the metadata directly onto the issue, about 80% of what a triager would fill in by hand, and posts a summary for a human to confirm. Everything lands on a project board, so for the first time the full picture of accessibility feedback is visible in one place.
Where the human stays. The pipeline proposes; it doesn't decide. An accessibility expert reviews the classification before work is routed, and anyone can trigger a manual rerun or push feedback back into the system when the model gets it wrong. That was deliberate. Severity scoring is a judgment call with real consequences — get it wrong and you either flood teams with false urgency or quietly deprioritize something that locks a person out of the product. The model is good at the first 80% and should not be trusted with the last 20%.
The teaching layer. Most triage systems close a ticket. This one explains the issue back to the person who reported it — what the barrier was, which guideline it maps to, why it happens. The fix is temporary; the understanding isn't. That's the part I'd rebuild first if I had to start over.
Results. Median resolution time went from 126 days to 52. Sev1 accessibility issues dropped 40% year over year. Tracked accessibility issues rose 300% as reports stopped disappearing, and resolution rates went from 16% to 84%.
Read the full write-up on the GitHub Blog (opens in new tab).