fixing-accessibility

Fix accessibility issues.

how to use

• /fixing-accessibility Apply these constraints to any UI work in this conversation.

• /fixing-accessibility <file> Review the file against all rules below and report:

  • violations (quote the exact line or snippet)
  • why it matters (one short sentence)
  • a concrete fix (code-level suggestion)

Do not rewrite large parts of the UI. Prefer minimal, targeted fixes.

when to apply

Reference these guidelines when:

• adding or changing buttons, links, inputs, menus, dialogs, tabs, dropdowns
• building forms, validation, error states, helper text
• implementing keyboard shortcuts or custom interactions
• working on focus states, focus trapping, or modal behavior
• rendering icon-only controls
• adding hover-only interactions or hidden content

rule categories by priority

priority	category	impact
1	accessible names	critical
2	keyboard access	critical
3	focus and dialogs	critical
4	semantics	high
5	forms and errors	high
6	announcements	medium-high
7	contrast and states	medium
8	media and motion	low-medium
9	tool boundaries	critical

quick reference

1. accessible names (critical)

• every interactive control must have an accessible name
• icon-only buttons must have aria-label or aria-labelledby
• every input, select, and textarea must be labeled
• links must have meaningful text (no “click here”)
• decorative icons must be aria-hidden

2. keyboard access (critical)

• do not use div or span as buttons without full keyboard support
• all interactive elements must be reachable by Tab
• focus must be visible for keyboard users
• do not use tabindex greater than 0
• Escape must close dialogs or overlays when applicable

3. focus and dialogs (critical)