zivtech

a11y-content-judgment

Load this skill when an audit needs the judgment-shaped WCAG criteria that scanners cannot decide — are page titles, headings, form labels, link text in context, and image alternatives actually useful, meaningful, and descriptive for the person relying on them (2.4.2, 2.4.6, 2.4.4, 1.1.1), and is navigation consistent across pages (3.2.3, 3.2.4)? It inventories every such element across a URL list, attaches deterministic heuristic flags, has a model draft a per-row judgment with a rationale, and hands the rows to a named human ratifier as a CSV. Output is always a DRAFT; a row becomes a criterion outcome only when a human ratifies it. Never use it to flip an outcome-map cell, to judge criteria that need interaction or assistive technology, or as a substitute for a11y-test's measurement.

a11y-critic

Use when you have an existing component, flow, or interface and need an evidence-backed accessibility design review after basic checks pass. Best for WCAG 2.2 compliance, focus management, ARIA pattern quality, semantics, and state communication gaps automated tools miss.

a11y-planner

Use when you know what component, flow, or interface you need but not yet the right accessibility approach. Best for turning WCAG 2.2 requirements into an accessible implementation plan with WAI-ARIA APG patterns before code hardens bad interaction and state patterns.

Testing & QA Listed

a11y-test

Use when you need to run real accessibility tests — Playwright keyboard interactions, axe-core scanning, visual regression, and WCAG 2.2 compliance checks. The measurement layer that feeds evidence into a11y-critic reviews.

Data & Documents Listed

acr-reporting

Load this skill whenever you are converting a finished audit-scope accessibility evaluation into an Accessibility Conformance Report (ACR) draft in the OpenACR format, validating or rendering OpenACR YAML, or preparing the handoff to GSA's ACR Editor (https://acreditor.section508.gov/). Report-level companion to bug-reporting: findings→issues is bug-reporting; evaluation-report→ACR is this skill. Output is always a DRAFT for human review and sign-off — never a final or signed ACR. Under no circumstances map an untested Level A/AA criterion to any adherence term, derive a conformance term from finding severity, or invent metadata values (contacts, dates, versions).

Data & Documents Listed

bug-reporting

Load this skill whenever you are filing, reviewing, or generating accessibility bug reports — whether from automated tool output, manual testing, or AI agent scans. The purpose of this skill is to make accessibility errors easier to report accurately, so that developers can reproduce, understand, and fix them without additional back-and-forth. Absolutely always include the required fields (URL, XPath, HTML snippet, WCAG SC, rule ID, severity, frequency) in every report. Under no circumstances file a vague report that omits the failing element, the WCAG criterion, or the steps to reproduce.

perspective-audit

Deep accessibility review from 7 access perspectives — activated by escalation from a11y-planner or a11y-critic when one or more perspectives are flagged at MEDIUM or HIGH alarm level.

a11y-workflow

Orchestrate the a11y accessibility lifecycle: scout → plan → critique → [perspective audit] → test → critique. Dual-mode: full lifecycle automation or step-by-step dispatch. Spawns specialist agents at depth-1 from the main session.

drupal-a11y-patch-eval

Evaluate a Drupal accessibility patch end-to-end: baseline evidence, patch hygiene, after-patch verification, manual/AT checks, critic gate, and upstream handoff. Evidence-gated — never VERIFIED without before/after proof under the same conditions.

a11y-role-audit

ARRM-based accessibility role audit — responsibility-based review lenses

maintain-accessibility-skills

Safely maintain the public accessibility-skills repository. Use when adding tracked-file hygiene scanners, proving whether reset or rebase work was lost, splitting mixed changes into focused commits, or recovering review-worthy commits made on the local default branch.

verify

How to verify changes in this prompt-only repo: reproduce committed evidence-harness recipes from scratch, don't re-run CI. Covers the evals/results/* harness pattern.