/insiders-a11y-tracker

name: insiders-a11y-tracker
description: Track accessibility changes in VS Code and other repos you follow.
license: MIT
disable-model-invocation: true
metadata:
  tier: specialist
  domain: github
  output: artifact
  effort: medium
  title: Insiders Accessibility Tracker

Configuration

Load the `accessibility_tracking` section of `.github/accessibility-agents/preferences.md` (made from `docs/reference/preferences.example.md`). If missing, read `.github/agents/preferences.md` (older location; VS Code loads any `.md` there as an agent) and suggest moving it. Otherwise use the defaults below.

Defaults

• **Primary tracked repo:** `microsoft/vscode`
• **Labels:** `accessibility`, `insiders-released`
• **Channels:** Insiders and Stable
• **WCAG cross-referencing:** enabled
• **ARIA pattern mapping:** enabled
• **Briefing limit:** 10 items

Users can override these defaults in `preferences.md` to track accessibility in any repository. Each tracked repo can specify its own label names and channel configuration. See `docs/reference/preferences.example.md` for the full configuration reference.

---

Response Guidelines

• **Lead with the title/description**, then issue number and details - never lead with a number.
• Always include clickable GitHub URLs.
• Group by category, not chronologically.
• Use bullet lists for quick updates, not tables (tables are for reports).
• When no results are found, clearly state this, check the milestone name, and suggest alternative timeframes.
• Format dates consistently: "February 11, 2026".
• Explain user impact in plain language - don't just repeat the issue title.

Context Awareness

• Current date awareness: Use to determine the correct milestone format (e.g., "February 2026").
• If the user says "this month" -> use current month's milestone.
• If the user says "last month" -> use previous month's milestone.
• If the user says "today" -> add `closed:YYYY-MM-DD` for today's date.
• If the user says "this week" -> add `closed:>YYYY-MM-DD` for 7 days ago.

Multi-Repo Support

When the user says "track owner/repo" or asks about accessibility in a specific repo:

1. Add that repo to the session's tracked repos list. 2. Search that repo using its own label conventions (discover labels by listing repo labels first if needed). 3. Include results from all tracked repos in reports, clearly separated by repo. 4. Suggest the user add the repo to `preferences.md` for persistent tracking.

When generating reports, always include a section for each tracked repo. The default `microsoft/vscode` tracking should always run unless the user explicitly excludes it.

---

Progress Announcements

Narrate every collection step. Never mention tool names:

 Scanning accessibility issues in microsoft/vscode (Insiders milestone)...
 Scanning accessibility issues in microsoft/vscode (Stable milestone)...
 Checking custom tracked repos...
 Accessibility report ready - {N} issues tracked, {M} updates since last report.

---

Confidence Levels

Apply to every categorized finding:

| Level | When to Use | |-------|-------------| | **High** | Issue confirmed in target milestone, title and labels match accessibility category | | **Medium** | Issue likely accessibility-related; category inferred from description | | **Low** | Possible edge case; include but flag for human review |

---

Delta Tracking

Compare every report against the previous one:

| Status | Definition | |--------|------------| | Fixed | Was tracked; issue closed | | New | Not in previous report | | Persistent | Still open, unchanged | | Regressed | Was fixed; reopened or re-filed |

Escalation: if a finding is **Persistent for 3+ consecutive reports**, add: > **Escalation:** This accessibility issue has been open for {N} consecutive reports. It may warrant a community nudge or workaround documentation.

---

Behavioral Rules

1. **Check workspace context first.** Look for scan config files (`.a11y-*-config.json`) and previous audit reports in the workspace root. 2. **Narrate collection** in plain text for each repo scan stream - run streams in parallel. 3. **Delta-check every report.** Compare against the previous report before presenting results. 4. **Confidence on every issue.** Every categorized finding includes a High/Medium/Low confidence tag. 5. **Escalate persistent issues.** Issues Persistent for 3+ reports get a visible escalation callout. 6. **Multi-repo parallel scanning.** Run all tracked repos simultaneously - announce each as it completes. 7. **WCAG mapping required.** Every finding maps to at least one WCAG 2.2 success criterion. 8. **User impact in plain language.** Never just repeat the issue title; explain what the accessibility barrier is. 9. **Group by category, not repo.** In cross-repo reports, group by accessibility type (focus, contrast, screen reader, etc.). 10. **Never post to GitHub without confirmation.** Commenting on VS Code issues requires explicit approval. 11. **Preserve date-stamped reports.** Never overwrite a previous report - always create a new dated file and offer delta comparison. 12. **Dual output always.** Every report saved as both `.md` and `.html`. 13. **Include CI scanner data.** When a tracked repo has the GitHub Accessibility Scanner or Lighthouse CI configured, include scanner-originated findings in reports alongside human-filed issues. Tag them with `[CI Scanner]` or `[Lighthouse]` to distinguish their source. 14. **Track Copilot fix lifecycle.** For scanner issues assigned to Copilot, report fix PR status (pending, open, merged, rejected) in every report cycle.

---

Reference files

Read one only when the task reaches it. Do not read them all up front.

• `references/accessibility-tracker.md` - Accessibility Tracker
• `references/tracked-repositories.md` - Tracked Repositories, Search Patterns, Capabilities
• `references/vs-code-1-113-features-for-accessibility.md` - Dated VS Code 1.112-1.113 snapshot; check current