Accessible Tabs & Accordions

Tabs and accordions are collapsible sections that organize content—like file folders or expanding lists. To make them accessible, first build a solid HTML foundation, then add keyboard support so users can navigate without a mouse, and finally use ARIA attributes so screen readers announce what's happening. The right sequence matters because adding fancy features to broken code just breaks it fancier. A banking app with inaccessible tabs locks blind customers out of account details, while an accessible accordion lets everyone navigate complex forms at their own pace. Notice this: Semantic HTML is always step one—ARIA is a enhancement layer, not a foundation.

Building accessible tabs and accordions follows a clear sequence. Start with semantic HTML: tabs use a list of buttons within a tablist container, each controlling a tabpanel; accordions use heading elements with button controls for each collapsible section. This structure gives you built-in keyboard accessibility and screen reader announcements before adding any JavaScript or ARIA.

Next, implement keyboard navigation following the W3C patterns. For tabs: arrow keys move between tabs, Enter/Space activates a panel, Tab moves into the active panel. For accordions: Enter/Space expands and collapses, optional arrow keys jump between headers, and Tab moves through all interactive elements in the page sequence. These standardized keystrokes work consistently because users encounter them across sites—changing them breaks learned expectations and creates confusion.

Then add ARIA attributes to fill semantic gaps: aria-selected marks active tabs, aria-expanded indicates open/closed state for accordions, and aria-controls links each control to its content panel. Without these, screen readers announce buttons but can't tell users which panel is currently displayed or whether a section is expanded. Common mistakes include adding ARIA to broken HTML (which compounds problems), skipping aria-expanded on collapsible sections (leaving screen reader users guessing), or implementing custom keystrokes that conflict with browser and assistive technology patterns.

The cognitive accessibility dimension matters too. Accordions reduce scrolling by hiding content until requested, which helps users with attention or processing limitations focus on one section at a time. However, hiding critical information behind interactions creates barriers—pricing pages that hide costs in accordions force extra clicks for everyone and make comparison difficult for users with working memory challenges. Use these patterns to organize related content, not to bury important information.

Research on cognitive accessibility indicates that information hiding patterns like accordions can both help and hinder. The W3C Cognitive Accessibility Guidance notes that showing information progressively helps users maintain focus and avoid overwhelm, but hiding critical information behind interactions creates barriers for users with memory, processing, or executive function limitations [3]. Kärpänen et al. (2023) discuss tools and guidelines for evaluating cognitive accessibility in web design [4].

Power, Freire, Petrie, and Swallow (2012) demonstrated that accessibility guidelines alone are insufficient—blind users encountered significant barriers even on sites that appeared technically compliant, highlighting the gap between specification and real-world implementation [5]. This research underscores that accessible tabs and accordions require not just correct markup, but user testing with people who actually use assistive technologies.

ARIA attributes are unsupported in older browsers (Internet Explorer 11 and below), though this matters less as usage declines. Some screen reader users report confusion with complex tab implementations, especially nested tabs or tabs within accordions. The region role recommended for accordion panels can create landmark proliferation when many panels are present, potentially overwhelming screen reader navigation. Automatic tab activation (panels change on arrow key focus) can cause disorientation if content loads slowly or if users prefer manual activation. Some developers overuse ARIA when native HTML elements would suffice—remember that semantic HTML provides accessibility foundations that ARIA cannot replicate. Finally, no pattern works for all users: some prefer all content visible for scanning, while others need progressive disclosure for focus management.