Read the Docs to learn how to automate your projects using GitHub Actions >
GitHub receives weekly accessibility grades across our core services. Until recently, when a service fell below a threshold, we relied on a fully manual remediation chain: someone read the report, opened an issue in the repository, guessed the owner, chased down status in a separate governance tracker, and tried to keep leadership informed. The outcome was predictable. We experienced slow reaction time, uneven follow‑up, and zero path to scale as services and checks grew.
We knew something needed to change, so we decided to use GitHub Copilot to turn that brittle process into an automated, auditable loop. This is the story of how we made that change.
The problematic workflow
First, let’s talk about where we started. Every Wednesday, accessibility grades would arrive in a tracking board, and services below a defined score required immediate remediation. Here’s how we’d (inefficiently) manage a failing grade when we spotted one:
- Manually create a tracking issue in the repositoryGuess at the right assigneeHope someone followed upManually track progress in the accessibility governance repository
This doesn’t scale. Teams got inconsistent outreach. Leadership had no visibility. Remediation took weeks instead of days.
Building with Copilot
How could we fix this? We needed a scalable, low‑maintenance way to trigger, track, and close accessibility remediation without constant manual coordination. We opted to use GitHub Copilot to automate the entire workflow. Our workflow now:
- Auto-creates GitHub Issues in service repositories when accessibility grades drop below a certain score.Updates existing issues with new grade data for persistent non-compliance.Cross-references remediation issues with customer relationship management (CRM) tracking boards.Auto-closes links when services return to an acceptable grade.Syncs assignees between governance boards and service teams.Mentions stakeholders for transparency without repo spam.
How Copilot changed the game
The traditional approach to building an internal automation like this would have meant drafting detailed requirements, prioritizing them into a team backlog, waiting for engineering capacity, and cycling through multiple sprint iterations before we saw working end‑to‑end value. That could take weeks, if not longer. Instead, we spent five to six hours in direct conversation with Copilot, rapidly prototyping and testing ideas.
Our working loop was intentionally lightweight. For each iteration, we roughly followed this pattern:
- Framed a single rule in plain language (e.g., detecting sustained non-compliance and ensuring an issue existed or was updated with current context).Asked Copilot to scaffold or adjust code (e.g., new helper, data parsing tweak, API refinement) instead of writing everything from scratch.Used a small synthetic fixture of grade snapshots (e.g., initial drop, continued drop, recovery) to exercise the logic locally.Reviewed the output (e.g., issue body, labels, assignees) and refined prompts to tighten naming, thresholds, or branching.Added guardrails: idempotency (i.e., skip if a valid issue was already open), simple dampening to avoid flip‑flop closures, and defensive handling for incomplete data.Logged high‑level decisions (e.g., “updated existing issue” vs “no action – compliant”) to quickly verify intent.Re-ran the fixture (plus a variation) to confirm no regressions, then commit and move to the next rule.
Because each iteration was scoped to a single behavior, Copilot’s suggestions stayed relevant and we avoided big refactors. When new edge cases emerged, like transient score dips or duplicate issue creation due to renamed services, we added another short loop instead of scheduling a meeting. This rapid cadence enabled us to converge on something production‑ready without a formal project plan.
From prototype to production
We first built a quick prototype to reliably detect a non‑compliant service, surface, or update a remediation issue, and keep ownership visible. We also wanted to prove we could achieve this without any human triage. The initial goal was a controlled rollout to a small set of services in a staging environment with historically known grade volatility. This way we could watch behavior under real conditions before rebuilding the workflow for broad deployment in a production environment.
Our planned rollout path was incremental:
- Prototype using a personal access token in a staging environment.Observe a handful of test weekly grade cycles in staging with mock service repositories and adjust thresholds or labels.Refactor the code and migrate to a GitHub App for proper security and scoped permissions.Deploy to production and roll out to all services that we track for accessibility compliance.Formalize governance reporting once noise was minimized.
To validate, we recorded a concise end‑to‑end demo showing an input grade change triggering automatic issue creation, cross‑linking, assignee sync, and subsequent update on a repeated failure. That artifact gave stakeholders the ability to evaluate the full experience asynchronously.
The reaction was decisive. Seeing live issues appear with clean structure and traceability accelerated approval to move beyond the prototype stage. We secured engineering partnership to productionize the flow, established a sandbox environment for hardening, and began implementing the GitHub App version with appropriate security and scale considerations.
The real impact
The impact came from two layers: the automation we introduced and the way Copilot changed who could build and iterate on it.
Automation outcomes:
- Remediation issues now appear (or update) promptly instead of waiting on manual triage, allowing service owners to immediately understand the policy requirements to resolve those issues and to hold themselves accountable when exceptions are requested.Ownership, status, and cross-links live in one place, giving leadership a trustworthy snapshot without ad‑hoc spreadsheets or pings. This also strengthens the partnership between accessibility program owners and engineering teams.Duplicate or stale outreach dropped because idempotent logic and dampening prevent noisy close and reopen churn.Governance effort shifted from clerical tracking to higher‑value analysis of systemic accessibility patterns, and enabled tighter governance controls.
Copilot-enabled delivery outcomes:
- A domain expert built the prototype, allowing engineers to stay focused on their critical roadmap work.Reduced context-switching for engineering. Partnership time was spent on security, scale, and production hardening instead of basic scaffolding.Lowered the barrier for future compliance or governance tooling, since there is now a repeatable pattern others can follow.
Contextually, this shift matters most at the moment accessibility grades signal new risk: Instead of waiting for someone to notice and start a manual chain, the system now surfaces the issue, assigns ownership, and keeps status visible. And it does all of this before follow‑up time decays. Thanks to Copilot, that system exists weeks sooner and can be iterated on by the person closest to the governance problem.
The bottom line is we moved from “let me write a ticket” to “here is working code with measurable impact on remediation speed and visibility.” That shift changes expectations for how fast internal compliance tooling can materialize.
The post How we automated accessibility compliance in five hours with GitHub Copilot appeared first on The GitHub Blog.
