How GitHub Copilot enabled accessibility governance process improvements in record time

We started building our accessibility governance program in 2022 when we adopted accessibility as a GitHub Engineering Fundamental, along with availability and security. Since then, we’ve continued to optimize and scale accessibility governance processes. 

This post explains how GitHub Copilot empowered an accessibility program manager to build a working prototype of a critical accessibility governance process improvement and enlist engineering resources to move it from prototype to production in record time.

Context

The primary construct of our accessibility governance program is services:

• A service may represent an entire website, an entire application, or a collection of pages, features, or backend functionality. 
• The accessibility compliance of each service is tracked and visible to program leads.
• The compliance status for each service is updated weekly and service owners are notified of changes.

The challenge

When new services are added or the compliance status of existing services is changed, service owners are notified. However, the problem is that we did not have an effective mechanism to prompt service owners to plan, schedule, and complete the work required to reach compliance.

This shortcoming had the following consequences:

1. Service owners sometimes delayed accessibility remediation work, extending potential negative impacts for users with disabilities.
2. Leadership could not quantify and manage accessibility compliance risk due to the lack of target dates for remediation.

The solution 

We used GitHub Copilot to automate a workflow that increases accountability for service owners, increases visibility  for leadership, and reduces barriers for users with disabilities. Our workflow now:

• Uses GitHub Actions to auto-create GitHub Issues that track accessibility remediation in service repositories when a service falls out of compliance.
• Includes all relevant information and guidance for service owners within remediation issues.
• Cross-references remediation issues with a GitHub Projects board that provides a global view for program managers and leadership.
• Syncs assignees between remediation issues and the project board. 
• Mentions stakeholders for transparency without repo spam.
• Auto-closes remediation issues when services are acceptable.

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:

1. Framed a single rule in plain language (e.g., detecting sustained non-compliance and ensuring an issue existed or was updated with current context).
2. Asked Copilot to scaffold or adjust code (e.g., new helper, data parsing tweak, API refinement) instead of writing everything from scratch.
3. Used a small synthetic fixture of accessibility compliance snapshots (e.g., initial drop, continued drop, recovery) to exercise the logic locally.
4. Reviewed the output (e.g., issue body, labels, assignees) and refined prompts to tighten naming, thresholds, or branching.
5. 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.
6. Logged high‑level decisions (e.g., “updated existing issue” vs “no action – compliant”) to quickly verify intent.
7. 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, create 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 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: 

1. Prototype using a personal access token in a staging environment.
2. Observe a handful of test weekly cycles in staging with mock service repositories and adjust thresholds or labels.
3. Refactor the code and migrate to a GitHub App for proper security and scoped permissions.
4. Deploy to production and roll out to all services that we track for accessibility compliance.
5. Formalize governance reporting once noise was minimized.

To validate, we recorded a concise end‑to‑end demo showing an input 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 changes 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 is triggered immediately when a service falls out of compliance and assigns the owner that is accountable for returning the service to compliance.

The bottom line is GitHub Copilot empowered a program manager from “let me write a feature request for the engineering team” to “here is working code with measurable impact on program goals.” That shift changes expectations for how fast internal compliance tooling can materialize.

Read the Docs to learn how to automate your projects using GitHub Actions >