accessible-ui-engineering

Accessible UI Engineering

Purpose

Make accessibility part of implementation and verification rather than a late lint pass.

When to use it

• During implementation and review of every interactive or content-bearing UI.

Instructions

1. Use native elements and semantics first; add ARIA only to express behavior native HTML cannot represent.
2. Give every control an accessible name, state, role, target size, and logical keyboard operation. Never remove focus visibility.
3. Manage focus on dialogs, navigation, errors, deletion, and dynamically added content; restore it to a sensible location.
4. Verify contrast, non-color cues, text resize/zoom, reflow, reduced motion, captions/alternatives, and high-contrast behavior when relevant.
5. Associate form labels, instructions, errors, and summaries; preserve entered values and move focus to actionable recovery.
6. Run available automated accessibility checks, then manually test keyboard, focus order, accessible names, announcements, and representative screen-reader paths.
7. Cite applicable WCAG criteria for blockers and distinguish automated coverage from manual or untested coverage.

Output format

Implementation notes and an accessibility report: tested paths, automated and manual evidence, blockers, WCAG references, fixes, and untested assistive technology.

Anti-patterns

• Treating zero automated findings as accessible.
• Adding ARIA to compensate for a non-semantic control.
• Subjective aesthetic feedback labelled as an accessibility blocker.

Verification checklist

• The complete task is keyboard-operable with visible focus and sensible recovery.
• Names, roles, states, contrast, zoom/reflow, motion preference, and errors were exercised.

Apply context-discovery before broad scanning: use a supplied context capsule first; otherwise check context frontmatter freshness, read .agent/context/routing.md, load only relevant summaries, and verify critical claims against source.