Accessibility & WCAG — high-level pointers (local fallback)

axew tells you which WCAG rule axe-core flagged. The detailed, current remediation per success criterion — how to fix each violation class, plus the manual-review checklist for what axe-core cannot automate (reading order, meaningful alt text, keyboard traps, caption accuracy) — lives in the team wiki (set OUTLINE + OUTLINE_API_URL and the report links them directly). This file is the minimal high-level fallback for when the wiki isn’t configured: direction only, deliberately not step-by-step, so there’s no detailed content to drift out of sync with the wiki.

• Critical/serious violations — real barriers; fix before shipping, they’re what fails the run.
• Color contrast — computed against the rendered page; adjust the color pair, not just the source hex value, since gradients/overlays change the effective contrast.
• Missing alt text / accessible names — every link, button and image needs one; a decorative image should be marked alt="", not left without an alt at all.
• Form labels — every input needs a programmatically associated label, not just placeholder text.
• ARIA misuse — an incorrect role or missing required attribute is often worse than no ARIA at all; prefer native HTML elements first.
• Heading / landmark structure — headings should nest without skipping levels; landmarks should be unique and meaningful.
• Manual review items — axe flags these because it cannot decide; a human still has to judge them, they are not a defect on their own.
• What axe never checks — keyboard traps, reading order, caption accuracy, and anything behind authentication all need a human pass; a clean automated run is not a WCAG AA certification.

Full playbook → the team wiki’s accessibility & WCAG standards.