Accordions vs Tabs: Why These Two ARIA Patterns Are Not Interchangeable

Most component libraries implement accordions and tabs the same way. They shouldn't.

Both patterns show a trigger and a panel of content. But the keyboard contract, ARIA roles and screen reader behavior are completely different for each — and mixing them up is one of the most common accessibility bugs I see in audits.

Here's the short version:

Accordions

• Multiple panels can be open at once
• Tab key focuses each trigger, Enter/Space toggles it
• Native <details>/<summary> handles this with zero JavaScript
• Full ARIA fallback: <button aria-expanded> inside a heading + aria-controls pointing to role="region"

Tabs

• Only one panel visible at a time
• Arrow keys navigate between tabs — NOT the Tab key
• Every inactive tab needs tabindex="-1" (roving tabindex) or keyboard users get stuck
• ARIA: role="tablist" > role="tab" + aria-selected > role="tabpanel"

Wire up the wrong keyboard pattern and keyboard users either can't access the content or have to fight through the component to get there.

I wrote the full breakdown — with the broken markup and the correct fix for each pattern — on the AccessGuard blog:

→ Accessible Accordions and Tabs: ARIA + Keyboard Patterns

It covers the exact WCAG criteria, when to use each pattern and which attributes most implementations get wrong. Happy to discuss any of it in the comments.