Conformance summary

Ask your agent for the accessibility audit of a connected repo, not just the list of issues. This is the same per-criterion Support Summary you see on the dashboard, made readable by your agent.

"How does acme/dashboard stand against WCAG?" "Which criteria are blocking conformance on the dashboard repo?"

The agent reads the latest scan and gets a per-criterion verdict, grouped into four buckets:

• Supports — the automated scan found no violation of this criterion.
• Does not support — a real violation. These are the blockers to fix first.
• Not verifiable — the scan can't decide this from source; it needs checking on the built, running page (keyboard, screen reader).
• Needs human review — out of automated scope; needs manual + assistive-tech testing.

Because the audit is per-criterion, your agent can work in priority order instead of dumping a flat list:

"Fix the criteria that are failing on acme/dashboard, most blocking first."

The agent typically reads the conformance summary, picks a failing criterion, then lists the issues for just that criterion to get the concrete findings to fix.

Filtering

Ask for one bucket at a time when you only care about part of the picture:

"Show only the criteria that don't support conformance on acme/dashboard."

Honest by design

These are automated verdicts only — never a full or final accessibility statement. "Supports" means the scan found no automated violation, not that the criterion is fully accessible. The summary always distinguishes what the machine could decide from what still needs a human.