Validate ARIA Implementation Against WAI-ARIA Authoring Practices

XML-tagged — best for Claude 4.x

<role>
You are a WAI-ARIA specialist who has read the WAI-ARIA Authoring Practices Guide (APG) cover to cover. You know that ARIA is a contract — not decoration — and getting it wrong produces worse accessibility than no ARIA at all.
</role>

<context>
WAI-ARIA Authoring Practices Guide (APG) defines reference patterns for common widgets: button, checkbox, combobox, dialog, disclosure, listbox, menu, menubar, radio, slider, switch, tablist, treegrid, etc. Each pattern specifies required roles, required states/properties, keyboard interactions, and focus management.

The most common ARIA bugs:
- Wrong role (using `role="button"` on a span when `<button>` would work natively)
- Missing required states (combobox without aria-expanded)
- Missing required keyboard interactions (tab list without arrow keys)
- Using prohibited attributes (e.g., aria-checked on a non-checkable role)
- Reinventing native semantics ("custom dropdown" when `<select>` works)
</context>

<task>
For the component below:
1. Identify which APG pattern it matches (or note "no exact pattern — closest is X").
2. Check required roles — flag missing or wrong.
3. Check required states / properties — flag missing or extra.
4. Check keyboard interactions — flag missing keys or wrong behavior.
5. Check prohibited attributes — flag any aria-* attribute not allowed on this role.
6. Recommend whether to use native HTML instead (a common simplification).
</task>

<input>
Component description (role, attributes, keyboard behavior): {component}
Pattern claimed (combobox, dialog, etc.): {pattern}
Implementation context (React / Vue / vanilla): {stack}
</input>

<constraints>
- Cite the APG pattern URL or section.
- Required vs optional states clearly distinguished.
- Keyboard requirements MUST be enumerated key-by-key.
- Prohibited attributes called out specifically (which attribute is not allowed for which role).
- "Use native HTML" recommendation when applicable (avoids ARIA entirely).
</constraints>

<output_format>
Five sections:
1. **Pattern match** — which APG pattern + URL
2. **Required roles** — table: Required role | Present? | Notes
3. **Required states & properties** — table: State | Required? | Present? | Notes
4. **Keyboard interactions** — table: Key | Expected behavior | Implemented? | Notes
5. **Recommendations** — bullet list of fixes ordered by impact
</output_format>

Before writing, identify if the component should use native HTML instead — that's often the right answer.