Accessibility governance on a faster track

GitHub made accessibility an Engineering Fundamental in 2022, alongside availability and security. Since then, the company has been refining how it governs accessibility compliance across its services. This post looks at how GitHub Copilot enabled an accessibility program manager to prototype and productionize a key governance workflow without waiting on a traditional engineering cycle.

The gap in compliance handling

GitHub’s accessibility governance program is organized around services—units that may represent a website, application, or collection of features. Each service has a compliance status that is tracked, updated weekly, and shared with its owner.

When a service’s compliance status changed, owners were notified. But there was no effective mechanism prompting them to actually plan, schedule, and complete the necessary remediation work. That gap led to two problems:

  1. Service owners sometimes delayed accessibility fixes, prolonging negative impact for users with disabilities.
  2. Leadership lacked target dates for remediation, making it hard to quantify or manage compliance risk.

Automating accountability

The solution was a workflow built on GitHub Actions. It automatically creates issues in service repositories when a service drops out of compliance, and those issues contain the context and guidance owners need to act. The issues are cross-referenced with a GitHub Projects board so program managers and leadership get a global view. The workflow also keeps assignees in sync between issues and the board, mentions relevant stakeholders without spamming repositories, and auto-closes remediation issues once a service returns to an acceptable state.

The automation shifts the burden: instead of waiting for someone to notice a compliance change and manually start a remediation chain, the system surfaces the issue, assigns ownership, and keeps status visible—immediately.

Prototyping without a feature request

Building internal tooling through traditional channels would have meant writing detailed requirements, prioritizing them into a team backlog, waiting for engineering capacity, and iterating across multiple sprints. That could take weeks or longer. Instead, the program manager spent five to six hours in direct, iterative conversation with Copilot to produce a working prototype.

The loop was deliberately lightweight and scoped to single behaviors. Each iteration roughly followed this pattern:

  1. State one rule in plain language—for example, detecting sustained non-compliance and ensuring an issue exists or is updated with current context.
  2. Ask Copilot to scaffold or adjust code—a new helper, data parsing tweak, or API refinement—rather than write everything from scratch.
  3. Exercise the logic locally using small synthetic fixtures of compliance snapshots: initial drop, continued drop, and recovery.
  4. Review the output—issue body, labels, assignees—and refine prompts for clearer naming, thresholds, or branching.
  5. Add guardrails for idempotency, dampening to avoid flip-flop issue closures, and defensive handling of incomplete data.
  6. Log high-level decisions like updated existing issue versus no action – compliant to verify intent.
  7. Re-run the fixture with variations to confirm no regressions, then commit and tackle the next rule.

Keeping each iteration to a single behavior meant Copilot’s suggestions stayed relevant and avoided large refactors. When new edge cases emerged—transient score dips, duplicate issue creation from renamed services—another short loop handled it. No meetings, no formal project plan, just rapid convergence on something production-ready.

Moving from prototype to production

The first prototype focused on reliably detecting a non-compliant service, creating or updating a remediation issue, and keeping ownership visible—all without human triage. The rollout plan was deliberately incremental:

  1. Run a prototype using a personal access token in a staging environment.
  2. Observe several test weekly cycles in staging with mock service repositories, adjusting thresholds and labels as needed.
  3. Refactor the code and migrate to a GitHub App for proper security and scoped permissions.
  4. Deploy to production across all tracked services.
  5. Formalize governance reporting once noise is minimized.

To validate the approach, the team recorded a concise end-to-end demo: an input change triggered automatic issue creation, cross-linking, assignee sync, and subsequent updates on repeated failure. That artifact let stakeholders evaluate the full experience asynchronously.

The result was decisive. Witnessing live issues appear with clean structure and traceability accelerated the approval to move past the prototype stage. Engineering partnership was secured for productionization, a sandbox environment was established for hardening, and work began on the GitHub App version with appropriate security and scale considerations.

Two layers of impact

The practical impact came from two distinct sources: the automation itself and the way Copilot changed who could build and iterate on such systems.

Automation outcomes:

  • Remediation issues appear or update promptly, so service owners immediately understand policy requirements and can act, or formally request an exception.
  • Ownership, status, and cross-links live in one place, giving leadership a reliable snapshot without ad-hoc spreadsheets or pings.
  • Duplicate or stale outreach is reduced, since idempotent logic and dampening prevent noisy close-and-reopen churn.
  • Governance effort shifted from clerical tracking to higher-value analysis of systemic accessibility patterns.

Copilot-enabled delivery outcomes:

  • A domain expert built the prototype, keeping engineers focused on their roadmap work.
  • Engineering time was spent on security, scale, and production hardening rather than basic scaffolding.
  • The approach established a repeatable pattern for future compliance or governance tooling.

The shift is most significant at the moment compliance changes signal new risk. Previously, that risk waited for someone to notice and start a manual process. Now the system triggers immediately, assigns ownership, and keeps the status visible before follow-up time decays. Copilot made it possible to go from a feature request to working code with measurable program impact—transforming expectations for how fast internal compliance tooling can materialize.