Here's a pattern we see constantly in audits: a site's text, images, and forms are in decent shape — and then a custom component undoes it. The newsletter popup that traps a screen reader. The tab panel that a keyboard can't reach. The carousel that whisks content away mid-sentence.
It's not carelessness. Browsers give built-in elements — links, buttons, checkboxes — their keyboard behavior and screen reader announcements for free. The moment a designer builds something custom out of styled boxes, all of that has to be recreated by hand, and it usually isn't. The component looks finished, works fine with a mouse, and silently fails for everyone else.
The fix isn't avoiding custom components. It's knowing what each pattern owes its users. Here's the short version for the four biggest offenders.
Modals: manage the focus, or lose the visitor
A modal dialog visually covers the page — but for a keyboard or screen reader user, the page underneath is still there unless you say otherwise. The classic failure: a discount popup appears, a screen reader user keeps reading the page behind it, and can neither find the popup nor get rid of it.
A well-behaved modal does four things:
- Moves focus into the dialog when it opens, so keyboard users land inside it immediately.
- Keeps focus inside while it's open. Tabbing past the last button wraps back to the first — never out into the hidden page behind.
- Closes on Escape. Every user expects it; many depend on it.
- Returns focus to where the user was when it closes, so they resume instead of starting over from the top of the page.
Miss any one of these and the modal becomes a trap. Get all four and it's just a dialog — which is the goal.
Tabs: arrow keys, not a wall of stops
Tabbed interfaces have a specific keyboard convention, and it surprises many designers: the Tab key moves you to the group of tabs, but arrow keys move between the tabs themselves. One press of Tab then jumps into the open panel's content.
Why it matters: imagine a pricing page with five tabs, each opening a panel with a dozen links. Without the convention, a keyboard user has to Tab through every link in every panel just to reach the last tab — dozens of keystrokes for what a mouse user does in one click. With it, the whole component takes three keys.
Tabs also need to announce themselves. A screen reader should hear "Features, tab, 2 of 5, selected" — not just "Features, link." That's the difference between understanding the interface and guessing at it.
Carousels: give people a pause button
Auto-advancing carousels are the pattern accessibility professionals wince at most, because motion the user didn't ask for causes problems on every axis: it yanks content away from slow readers, it disorients screen reader users when the page changes under them, and it's genuinely difficult for people with attention or vestibular conditions.
If a carousel earns its place on your page, it owes users control:
- A visible pause/stop button — this is a hard requirement in accessibility guidelines for anything that auto-advances. Pausing on hover isn't enough, because keyboard and touch users don't hover.
- Reachable previous/next controls and slide indicators, operable by keyboard, with labels that say what they do ("Next slide," not an unlabeled arrow).
- Sensible announcements — moving to a new slide should tell assistive tech where it is ("Slide 3 of 5"), and slides that are off-screen shouldn't be focusable.
And it's worth asking the honest question: if nobody's expected to see slides two through five, do you need a carousel at all? A static section with clear headings is accessible by default.
Menus: semantics tell the truth, hover tells a lie
Navigation menus break in two classic ways. First, hover-only dropdowns: if a submenu only appears on mouse hover, keyboard users can never open it, and touch users get inconsistent behavior. Anything that opens a submenu should be a real button that works on click and Enter, announces whether it's expanded or collapsed, and closes on Escape.
Second, fake semantics. When a menu is built from generic containers, a screen reader announces nothing useful — the user hears disconnected text and has to infer there's a navigation structure at all. Built from real lists, links, and buttons inside a labeled navigation region, the same menu announces itself properly: "Navigation, list, 6 items." Same pixels, completely different experience.
Also: keep hover targets forgiving. A dropdown that snaps shut when the pointer drifts two pixels off-course punishes anyone with a tremor — and honestly, everyone else too.
How to test in ten minutes, no tools required
Two checks catch the majority of custom component failures:
- Put down the mouse and tab through the page. Can you reach every control? Can you always see where you are? Can you open the menu, operate the tabs, escape the modal? If you get stuck or lost, so do your visitors.
- Turn on the screen reader you already have — VoiceOver on a Mac (Cmd+F5) or Narrator on Windows — and try your main components. You don't need to be an expert; if what you hear doesn't tell you what the component is or what it's doing, that's your finding.
For everything these quick checks don't catch, AllAccessible's audits surface component-level issues across your pages in plain language, and AllAccessible AI drafts suggested fixes that your team reviews and approves before anything ships. Custom components are exactly where that human judgment earns its keep.
Get started with AllAccessible and find out what your components sound like to the people using them.
Frequently Asked Questions
- Why do custom components break accessibility so often?
- Browsers give built-in elements like links, buttons, and checkboxes their keyboard behavior and screen reader announcements for free. When a designer builds something custom from styled boxes, all of that must be recreated by hand — and usually isn't. The component looks finished and works with a mouse, but silently fails for keyboard and screen reader users.
- What does an accessible modal dialog need to do?
- Four things: move focus into the dialog when it opens, keep focus inside while it's open (tabbing past the last control wraps to the first), close on Escape, and return focus to where the user was when it closes. Miss any one and the modal becomes a trap for keyboard and screen reader users.
- How should keyboard navigation work in a tabbed interface?
- The Tab key moves to the group of tabs, arrow keys move between the individual tabs, and one more press of Tab jumps into the open panel's content. Without this convention, a keyboard user might need dozens of keystrokes to reach the last tab; with it, the whole component takes three keys. Tabs should also announce themselves as 'tab, 2 of 5, selected' rather than as plain links.
- Are auto-advancing carousels bad for accessibility?
- They're the pattern accessibility professionals wince at most: unrequested motion yanks content from slow readers, disorients screen reader users, and affects people with attention or vestibular conditions. If you keep one, accessibility guidelines require a visible pause/stop button (hover-pause isn't enough), keyboard-operable labeled controls, and slide announcements — though a static section with clear headings is often the better answer.