GitHub's internal accessibility agent has reviewed 3,535 pull requests and resolved 68% of flagged issues. The agent runs automatically against any pull request that touches front-end code, catching WCAG violations before they reach production. Its five most common findings map directly to WCAG 2.1 criteria: semantic structure (1.3.1), accessible names for controls (4.1.2), status messages (4.1.3), text alternatives (1.1.1), and logical focus order (2.4.3). These are not edge cases. They are the baseline failures that make GitHub unusable for people who rely on screen readers or keyboard navigation.
The agent serves two functions: answering accessibility questions in real time via Copilot CLI and the VS Code integration, and filing automated code suggestions directly on pull requests. The screenshot in the original post shows it catching a flex-direction: row-reverse layout that created a mismatch between DOM order and visual order, a violation of WCAG 1.3.2, and suggesting a one-commit fix. GitHub credits its existing infrastructure, a structured issue log, reproduction steps, and verified fix tracking, as a prerequisite for the agent working at this fidelity. Organizations without that foundation will not get the same results.
The legal context makes this more than an engineering curiosity. The European Accessibility Act is active now. Title II of the ADA will require WCAG 2.1 AA compliance by April 2027. GitHub is not publishing this as a product announcement. They are publishing it as a methodology post, including what failed, to help other teams replicate or avoid their path. The process details, scope decisions, and lessons learned are why the full article is worth reading.
[READ ORIGINAL →]