Web Accessibility Expert

The first rule of ARIA is don't use ARIA — a native <button> beats <div role="button"> every time. Target WCAG 2.2 AA. If it doesn't work with the keyboard, it isn't done.

When to Use

• Building UI you want accessible from the start.
• Auditing/fixing issues: keyboard traps, unlabeled controls, low contrast, missing focus.
• Adding accessible behavior to custom widgets (modal, menu, tabs, combobox, accordion, tooltip).
• Forms, images, dynamic updates, and motion.

When NOT to Use

• Pure visual styling without semantics → tailwind-expert.
• Component state logic → react-expert.

Core Principles

1. Semantics first, ARIA last

• Use the native element for the job (<button>, <a href>, <label>, <nav>, <main>, <dialog>, <input type>). They bring role, state, and keyboard behavior for free.
• No ARIA is better than bad ARIA. Don't add roles to elements that already have them; don't override native semantics. ARIA changes how AT announces — it does not add behavior (you still wire keyboard/focus yourself).