lbql-yhl 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
- Define the task, users, supported browsers/AT, input methods, and failure recovery. Start with
assets/acceptance-criteria-template.md. - Choose native HTML first. Load
references/semantics-and-names.mdfor structure, native controls, accessible names, descriptions, and dynamic updates. - 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.
- Design for visual and input adaptation using
references/visual-input-and-motion.md; distinguish WCAG requirements from product goals and exceptions. - 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.
- Verify with
references/testing-and-evidence.mdand the design, implementation, and release templates. Record tool, version, scope, manual tasks, actual browser/AT combinations, failures, and blocked or not-applicable items. - 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
| Need | Load |
|---|---|
| Standards status, source authority, or exact links | references/source-index.md |
| Native semantics, labels, accessible names, landmarks, live updates | references/semantics-and-names.md |
| Tab order, focus visibility, traps, restoration, route changes | references/keyboard-focus-and-routing.md |
| Labels, validation, recoverable errors, authentication | references/forms-errors-authentication.md |
| Modal dialogs, disclosure, responsive navigation | references/dialogs-disclosures-navigation.md |
| Tabs, comboboxes, listboxes, grids, menus, other composites | references/composite-widgets.md |
| Contrast, reflow, zoom, targets, drag, motion, media | references/visual-input-and-motion.md |
| Automated checks, manual protocols, AT matrix, evidence | references/testing-and-evidence.md |
| Framework or skill boundary | references/routing.md |
| Validate common outcomes without claiming conformance | references/outcome-probes.md |
Decision Rules
- Treat WCAG 2.2 success criteria, HTML/ARIA specifications, and informative tutorials/patterns as separate layers. See
references/source-index.md. - Use WAI-ARIA 1.2 only when native host-language semantics do not provide the required behavior. ARIA changes semantics; it does not create keyboard behavior or visual presentation.
- Use the Accessible Name and Description Computation 1.2 algorithm for edge cases. Do not substitute a priority mnemonic; inspect the computed accessibility tree and name.
- For a modal, prefer
<dialog>.showModal()when it supports the target environment. Keep background content unavailable/inert, choose initial focus for the content and task, provide a visible close path, and return focus logically. Do not hide a backdrop witharia-hiddenor hide an ancestor of the dialog. - Treat ordinary responsive navigation as a disclosure over ordinary links, not an ARIA menu. Use menu semantics only with the application-menu keyboard contract.
- Target Size (Minimum) is 24 by 24 CSS pixels at WCAG 2.2 AA, subject to its spacing, equivalent, inline, user-agent, and essential exceptions. A larger target may be a product goal.
Completion
Stop when each acceptance criterion has direct evidence or a recorded failed, blocked, or not-applicable result. Report residual risk and the exact evidence boundary; do not turn absent testing into a pass.
When Not To Use
- Do not use this skill as a replacement for product discovery, visual design, or framework-specific API documentation.
- Keep the work focused on accessibility behavior, interaction contracts, evidence, and conformance boundaries; route unrelated concerns to the relevant project guidance.
- Consult the current official documentation for the chosen framework or component library after defining the semantic and interaction contract.