Accessibility Audit Stinger

Accessibility Audit Stinger

Forge status: stages 1-6 complete. Stage 7 (Register: beekeeper-suit pairing registration, deploy, sync references across harness targets) has not run yet. Everything below this line is grounded, cited content, not a structural stub; stage 7's remaining work is registration and distribution, not authorship.

You are equipping accessibility-audit-worker-bee, part of the Website Auditor by Legion Code Inc. plugin. Full scope and acceptance criteria: prd-013-accessibility-audit.

Every factual claim this skill makes traces to a downloaded primary source in references/research/raw/, unless explicitly marked as this Stinger's own construction (the checklist's full success-criteria scaffold, the 0-100%/rating-band formula, the AA/AAA-style band definitions) with the reason stated at the point of use. This Stinger's raw archive is thin by design: two sources, both concentrated on the European Accessibility Act's WCAG-version mapping and EU enforcement, neither documenting per-criterion WCAG testing methodology or non-EU regimes. Read references/research/distilled-accessibility-audit.md first for exactly what is and is not covered before treating anything as settled.

When to use this skill

• Wave W5 of every audit run, reading only site-data/, writing only to 06-accessibility/.
• Any request specifically about accessibility/WCAG conformance for a given site or page.
• Determining whether an audited party qualifies for the EAA's Article 4(5) microenterprise exemption before framing findings as EAA-compliance risk.
• Deciding what WCAG version to score against, and whether WCAG 2.2 items should be reported as a compliance requirement or a forward-looking indicator.

When not to use this skill

• Auditing this plugin's own codebase for accessibility issues in its own UI (there is none; this is a CLI/agent toolset). If a future component needs internal-product accessibility review, that is a different scope than this external-site auditor.
• Producing a legal EAA-conformance determination. This skill produces an audit input; the audited party's own counsel makes conformance determinations.
• Non-EU accessibility regimes (US ADA/Section 508, etc.). This Stinger's archive does not cover them; flag the gap rather than answering from unsourced general knowledge, per guides/05-manual-vs-automated-confidence-and-non-goals.md.
• Full manual accessibility audits requiring real assistive-technology user testing. This is an automated-plus-heuristic pass; say so, per PRD-013's stated non-goal.

Procedure

Full step-by-step in guides/01-audit-procedure.md. Summary: confirm site-data/ exists, run the scope gate (guides/03), run shared/scripts/a11y-scan.py for the automatable subset, walk the full checklist (references/templates/wcag-2.1-aa-checklist-scoring-table.md) for every remaining row, roll up the 0-100% score and assign the AA/AAA-style band (guides/04), write the dated accessibility statement (never an unqualified compliance verdict), and write output plus the evidence-index update per guides/06.

References map

Load on demand; do not read everything up front.

Related bees and stingers

• accessibility-audit-worker-bee - this Stinger's paired Bee.
• audit-scoring-stinger - reads this pair's 06-accessibility/ output in wave W7; the category-weight placement of this pair's leaves inside the build plan's eight-category table is an unresolved handoff item, named explicitly in guides/04-scoring-and-rating-bands.md section 5, for that pair's own forge to settle.
• site-crawler-stinger - upstream dependency; this pair reads site-data/ that pair writes.
• web-security-posture-stinger - sibling Wave-5 pair; both read site-data/ independently with no write contention, no shared scope overlap beyond the workspace.

Quality bar

A pass is done when: guides/01 through guides/06 were followed in order, every checklist row is scored with an evidence pointer and justification or explicitly marked N/A, the 0-100% score and AA/AAA-style band are computed via the sourced formula and never presented without the dated accessibility statement alongside them, the scope gate ran and its result is recorded regardless of outcome, the WCAG 2.2 forward-looking band is reported separately from the AA baseline, the category-placement gap is flagged rather than guessed, and 06-accessibility/ plus _shared/evidence-index.md are fully written per references/templates/accessibility-findings-output-template.md.

Critical Directive

• You must read all files and context contained within your skill.
• In the event your core knowledge does not provide sufficient guidance you must make every attempt to search the internet, related knowledge base documentation files, and other available resources to supplement your knowledge prior to proceeding with your task.
• Additional related skills can be found here:
  • accessibility-audit-worker-bee - this Stinger's paired Bee.

Ship Gate decision

Does not apply. The Ship Gate (security-stinger, then quality-stinger, then github-repo-health-stinger) governs committing code changes to a repository this plugin's own operator owns. This Stinger equips an external, read-only audit of a third-party site; it produces report artifacts inside the engagement workspace (06-accessibility/), not a code change to this plugin's repository, so no Ship Gate applies to its own output. If a future engagement's findings lead to the operator editing their own codebase based on this report, that edit (if made in a repo this plugin's operator owns) would separately go through the Ship Gate via the existing security-worker-bee/quality-worker-bee/github-repo-health-worker-bee chain, not through this pair.