Fix UI Accessibility Issues

A prioritized accessibility rulebook for reviewing and fixing UI code, invoked as /fixing-accessibility (apply to any UI work in the conversation) or /fixing-accessibility <file> (review a file and report violations with the exact snippet, why it matters, and a concrete fix) - explicitly preferring minimal, targeted fixes over large rewrites. Rules are grouped into nine priority categories: accessible names (critical - every control needs one, icon-only buttons need aria-label, links need meaningful text), keyboard access (critical - no div/span buttons without full keyboard support, no tabindex greater than 0, Escape closes dialogs), focus and dialogs (critical - modals trap focus, restore it to the trigger on close), semantics (high - native elements over role hacks, no skipped heading levels), forms and errors (high - errors linked via aria-describedby, invalid fields set aria-invalid), announcements (medium-high - aria-live for critical errors, aria-expanded/aria-controls for expandable controls), contrast and states (medium - sufficient contrast, keyboard equivalents for hover-only interactions), media and motion (low-medium - correct alt text, prefers-reduced-motion respected), and tool boundaries (critical - don't refactor unrelated code or migrate UI libraries unless asked).

<button aria-label="Close"><svg aria-hidden="true">...</svg></button>

Use it when adding or changing buttons, links, inputs, menus, dialogs, tabs, or dropdowns, building forms with validation and error states, implementing keyboard shortcuts or focus trapping, rendering icon-only controls, or adding hover-only interactions.

Input: UI code being written or an existing file to review. Output: either constraints applied inline to new UI work, or, for a file review, a violation-by-violation report - a quoted snippet, why it matters, and a concrete code-level fix - fixing critical issues (names, keyboard, focus, tool boundaries) first and preferring native HTML before adding ARIA.

Frontend developers who want a concrete, priority-ordered accessibility checklist and quotable fixes rather than a general "make it accessible" reminder.

Its common-fixes reference also covers converting a clickable div into a native button (preserving the same click handler) and linking a form error to its input with matching aria-describedby/id attributes plus aria-invalid="true" - concrete before/after pairs rather than abstract rules. For complex widgets like menus, dialogs, or comboboxes, it recommends established accessible primitives over custom-built behavior. It also names disabled-submit-button explanations and toast-only critical messaging as specific anti-patterns: a disabled action should say why, and a toast must never be the sole way a critical status reaches the user.