Web Accessibility

Accessibility is successful task completion and recovery for disabled people, not a tool score. Define observable requirements before implementation, prefer native platform behavior where it fits, and gather bounded evidence in the supported browser and assistive-technology (AT) environment.

Workflow

1. Define the task, users, supported browsers/AT, input methods, and failure recovery. Start with assets/acceptance-criteria-template.md.
2. Choose native HTML first. Load references/semantics-and-names.md for structure, native controls, accessible names, descriptions, and dynamic updates.
3. Specify every interactive state: trigger, role/name/state/value, keyboard commands, focus entry/exit/return, pointer alternative, errors, and visible feedback. Load the focused pattern reference.
4. Design for visual and input adaptation using references/visual-input-and-motion.md; distinguish WCAG requirements from product goals and exceptions.
5. Implement only after the contract is defined. For custom composite widgets, first evaluate a proven native or maintained component in the chosen stack; APG examples are informative guidance, not production proof.
6. Verify with references/testing-and-evidence.md and the design, implementation, and release templates. Record tool, version, scope, manual tasks, actual browser/AT combinations, failures, and blocked or not-applicable items.
7. Do not issue a WCAG conformance or general accessibility verdict from an automated scan. A conformance claim needs a complete, scoped evaluation outside this skill's automatic verdict.

Load On Demand