Accessible Tabs: Why Tabbed Content Fails Screen Readers (and How to Check Yours)

Tabs are everywhere. Product pages use them to split “Description,” “Specifications,” and “Reviews.” Pricing pages use them to switch between “Monthly” and “Annual.” Service businesses use them to organize “What we do,” “Pricing,” and “FAQ” into one tidy box instead of a long scroll. They feel clean and professional, and that is exactly why they are so popular.

They are also one of the most commonly broken accessibility patterns on the web. A tab strip that works perfectly with a mouse can be completely unusable for someone navigating by keyboard, and can read as a confusing jumble of disconnected buttons to someone using a screen reader. The worst part is that nothing looks wrong. The page passes a casual glance, an automated scanner often gives it a clean bill of health, and you would never know there was a problem unless you tried to use it the way a person with a disability does.

This guide explains, in plain English, why tabs break, how to check yours in about five minutes without writing a single line of code, and what to ask your developer or website builder to fix. No jargon, no DevTools.

What tabs are supposed to do

A proper set of tabs is a small, well-defined pattern with a real name: a “tab list.” It has three parts working together. There is the row of tabs you click (the tab list), the panel of content that each tab reveals (the tab panel), and an invisible set of relationships that tells assistive technology how they connect.

When it is built correctly, a screen reader user hears something like: “Tab list. Description, tab, one of three, selected.” They know instantly that they have landed on a group of tabs, how many there are, and which one is active. When they switch tabs, the screen reader announces the new selection and the content updates. Keyboard users can move between tabs with the arrow keys and jump straight into the revealed content. Everyone gets the same tidy, organized experience — they just get to it through different doors.

The problem is that this pattern almost never survives contact with a real website. Most tabs you see in the wild are not built as a tab list at all. They are just a few styled links or buttons sitting above some divs that get shown and hidden with a bit of JavaScript. To a sighted mouse user, that looks identical to real tabs. To everyone else, the illusion falls apart.

The four ways tabs commonly fail

1. They are invisible as a group. If the tabs are coded as plain links or generic clickable elements, a screen reader has no idea they form a set. It does not announce “tab list,” it does not say “one of three,” and it does not indicate which tab is currently selected. The user hears three unrelated links with no clue that clicking one hides the content behind another. They may read the first panel, move on, and never realize two-thirds of the page existed.

2. You cannot reach them with a keyboard. Many people never touch a mouse — because of a motor disability, a tremor, low vision, or simply preference. They navigate with the Tab key and arrow keys. If your tabs only respond to a mouse click, or if pressing Tab skips right over them, that content is locked away. This is one of the most common and most serious accessibility failures, and it maps directly to WCAG success criterion 2.1.1 Keyboard, a Level A requirement — the most basic tier of the standard.

3. The selected tab is a mystery. Sighted users can see which tab is active because it is a different color or has an underline. But if the only signal is color, two groups of people are excluded: screen reader users, who cannot see color at all, and people with low vision or color blindness, who may not perceive the difference. The active state has to be communicated in a way that does not rely on sight alone. Relying on color by itself also runs into WCAG 1.4.1 Use of Color.

4. Focus gets lost when you switch. When someone activates a tab and the panel changes, their place on the page should move sensibly to the new content or stay on the tab. On badly built tabs, activating a tab can throw the user back to the top of the page, or leave their invisible cursor stranded on content that just got hidden. It is disorienting, and for a screen reader user it often means they cannot find the content the tab was supposed to reveal.

How to check your tabs in five minutes

You do not need special software or technical skill. You need a keyboard and about five minutes. Here is the routine.

Step 1: Put the mouse away. Physically move your hand off the mouse or trackpad. You are going to navigate using only the keyboard, the way a large share of your visitors do every day.

Step 2: Tab to the tabs. Press the Tab key repeatedly and watch where the highlight — the focus outline — travels. It should move through your page in a logical order and eventually land on your tab strip. If pressing Tab never reaches the tabs at all, that is failure number two above: keyboard users cannot get there.

Step 3: Try the arrow keys. Once focus is on a tab, press the Left and Right arrow keys (or Up and Down). In a properly built tab list, the arrows move you between tabs. This is the expected behavior, and its absence is a strong sign the tabs are fake. If arrows do nothing and you have to Tab through every single tab one at a time, the pattern is not implemented correctly — though it may still be operable, which is better than nothing.

Step 4: Watch the focus outline. As you move between tabs, can you always see a clear outline or ring around the tab you are on? If the outline is invisible, faint, or has been deliberately removed, keyboard users are navigating blind. A visible focus indicator is required by WCAG 2.4.7 Focus Visible.

Step 5: Switch a tab and look for your place. Activate a different tab with Enter or Space. Does the corresponding content actually appear? After switching, press Tab again — does focus move into the newly revealed content, or does it jump somewhere strange? You are checking that switching tabs does not strand or disorient the user.

Step 6: Listen to it. This is the most revealing test. Turn on the screen reader already built into your device — VoiceOver on a Mac or iPhone, Narrator on Windows, TalkBack on Android — and navigate to your tabs with your eyes closed or the screen dimmed. Do you hear the word “tab”? Do you hear how many there are and which one is selected? Or do you just hear a string of link names with no structure? If it sounds like a confusing list of buttons, your sighted visitors and your screen reader visitors are having completely different experiences.

If your tabs pass all six steps, congratulations — you are in a small minority. If they fail two or three, you are entirely normal, and the fixes are well understood.

What to ask for when you fix it

You may not be the person who edits the code, and that is fine. Your job is to describe the problem clearly and ask for the right outcome. Here is what to hand your developer, your agency, or the support team for your website builder.

Ask them to implement the tabs using the standard “tabs” design pattern with proper roles — specifically the tablist, tab, and tabpanel roles, with aria-selected marking the active tab and each tab connected to its panel with aria-controls. Those are the technical ingredients that make a screen reader announce the group correctly. You do not need to understand the details, but naming them signals that you know what “done” looks like and saves a long back-and-forth.

Then ask for three behaviors in plain terms: the tabs must be reachable and operable with the keyboard alone, including arrow-key movement between tabs; the currently selected tab must be indicated by more than just color; and there must be a clearly visible focus outline that has not been stripped out with CSS. If you use a page builder or a theme, ask whether its built-in tabs component is accessible — many are now, but plenty of older themes and third-party “tab” plugins are not, and it is fair to ask before you rely on one.

One more practical tip: if your tabbed content is important for SEO or for people who print or share pages, remember that content hidden inside inactive tabs can be harder for some users and some tools to reach. For genuinely essential information — your prices, your return policy, your contact details — consider whether tabs are the right container at all, or whether an accordion or a plain scrolling section would serve more people with less risk.

Tabs are not the enemy — broken tabs are

None of this means you should rip every tab off your site. Tabs are a genuinely useful way to organize related content, and when they are built to the standard they work beautifully for everyone, including screen reader and keyboard users. The trouble is that “looks like tabs” and “works like tabs” are two very different things, and the gap between them is invisible until someone who relies on assistive technology tries to use your page.

The reassuring news is that this is a solved problem. The accessible tabs pattern is well documented, most modern frameworks and page builders now ship a version that gets it right, and the fixes rarely require rebuilding anything. The hard part is simply knowing the problem exists — and now you do. Spend the five minutes with your keyboard and your screen reader, and you will know exactly where you stand.

We’re building a simple accessibility checker for non-developers — no DevTools, no jargon. Join our waitlist to get early access.