Accessibility Anti-Patterns: The Dangers of Tooltips, Carousels, and Custom Selects

Introduction

When building accessible design systems, the true measure of success isn't just about what components we include and build, but frequently about what components and patterns we choose to actively omit. Accessibility in design systems doesn't just mean making everything "accessible" through brute force ARIA attributes; it requires a critical evaluation of everyday UI components and deciding which ones inherently create insurmountable barriers and hostile user experiences for people with disabilities. A mature design system acts as an opinionated guide, actively encouraging consuming product teams to seek better, more inclusive alternatives rather than reaching for flawed defaults.

Among the most common offenders found in modern web interfaces are tooltips, custom-styled selects (often known as dropdowns, listboxes, or comboboxes), and carousels. These three components frequently represent accessibility anti-patterns. While they may satisfy aesthetic desires or internal stakeholder demands, they consistently introduce significant cognitive and technical barriers for people relying on screen readers, navigating via keyboards or switch devices, or experiencing cognitive disabilities.

This article dives deep into the technical reasons why these popular UI components fail, how they create massive barriers, and why design systems should systematically exclude them or heavily constrain their usage based on the "Foundations of Accessible Design System Patterns."

---

The Problem with Tooltips

Hiding Crucial Information

At their core, tooltips are inherently flawed because they hide information. If content is important enough that a user requires it to understand the UI, it should be displayed plainly for all people, without being hidden behind a hover or focus state. Tooltips are often indicative of poor UX design, acting as a crutch for interfaces that are not intuitive or self-explanatory.

By asking users to perform an additional physical and cognitive task simply to understand a control's purpose or an input's requirement, we penalize everyone. This is especially damaging for those with cognitive disabilities who may struggle with working memory or require distraction-free interfaces. Information hidden behind tooltips will not be as readily consumed as useful information placed in visual proximity to decisive UI features.

Screen Reader and Keyboard Navigation Barriers

From a technical perspective, tooltips present an incredibly common and persistent barrier for screen reader users and keyboard-only users. The fundamental problem lies in the lack of a standardized, native HTML element for tooltips, which means there is no common, universally supported convention to define their accessible name, role, state, or keyboard action.

When developers attempt to build custom tooltips, they frequently rely on mouse hover events (mouseenter / mouseleave), entirely excluding users navigating with keyboards, switch devices, or touchscreens. Even when keyboard focus (focus / blur) is implemented, screen readers may not announce the tooltip's content if the ARIA attributes (such as aria-describedby or aria-labelledby) are not perfectly wired to the trigger element.

Furthermore, tooltips often fail the WCAG 2.1 Success Criterion 1.4.13: Content on Hover or Focus. This criterion demands that tooltips must be:

• Dismissable: Users must be able to dismiss the tooltip without moving their pointer or keyboard focus (typically via the Escape key). Custom tooltips rarely implement this correctly.
• Hoverable: If a user moves their pointer over the tooltip itself (perhaps to read it with a screen magnifier), it must not disappear.
• Persistent: The tooltip must remain visible until the hover or focus is removed, the user dismisses it, or its information is no longer valid.

Instead of fighting these technical battles and risking failure, the most accessible approach is to omit tooltips entirely from the design system. Encourage consuming teams to write UI text that is intuitive and self-explanatory, placing necessary instructions or descriptions in plain text directly adjacent to the relevant controls.

---

The Danger of Custom-Styled Selects (Dropdowns/Comboboxes)

The Illusion of Control

Designers and developers often harbor a deep disdain for the native HTML <select> element because its dropdown surface (the list of options) cannot be fully styled using CSS across all browsers and operating systems. This aesthetic frustration leads teams to build custom-styled selects using <div>, <span>, and <ul> elements, heavily decorated with CSS and driven by complex JavaScript frameworks (e.g., custom Angular Material dropdowns).

However, there are precisely zero good reasons to replace the native HTML <select> element in standard forms. The native element is inherently accessible and provides all the built-in features necessary to present a pop-out list of options reliably.

The Complexity of Replicating Native Behavior

A custom dropdown cannot replicate the robust, nuanced functionality of a native select element across every platform (macOS, Windows, iOS, Android, and ChromeOS). Each operating system and browser combination has slightly different keyboard actions, touchscreen gestures, and semantic expectations.

When building a custom select, developers must manually recreate years of browser engineering, including:

• Keyboard Navigation: Arrow keys to navigate options, Enter or Space to select, Escape to close, and type-ahead functionality (typing the first few letters of an option to jump directly to it).
• Focus Management: Managing aria-activedescendant or manually moving tabindex as the user navigates the custom list, while ensuring focus returns to the trigger button when closed.
• Screen Reader Semantics: Applying complex ARIA roles such as combobox, listbox, and option, along with dynamic states like aria-expanded and aria-selected.
• Mobile Experience: Native selects automatically trigger the OS-level UI (like the iOS wheel picker or Android modal list), which are highly optimized for touch and mobile screen readers. Custom selects force users into a faux-dropdown that often breaks on small screens, requires awkward scrolling, or zooms unpredictably.

It is incredibly expensive to build a custom select correctly. Even if built perfectly on day one, without consistent, rigorous maintenance against evolving browser standards and assistive technologies, it will inevitably degrade. It will quickly become inaccessible to people with motor disabilities using keyboards or switch devices, and to people using screen readers who rely on standard semantic structures.

The native HTML <select> element can be completely styled in its collapsed state (the trigger button itself). The options surface styling is provided by the operating system and does not require redesign. Embracing the native element is a massive victory for accessibility, performance, and long-term maintainability.

---

The Hostility of Carousels

Content Overload and Cognitive Load

Carousel slideshows are almost universally a compromise between competing stakeholders who cannot decide which content should lead, and therefore choose to display all of it in a rotating space. This results in a hostile user experience that rarely receives engagement beyond the very first slide.

Even "accessible" carousels deliver an immense additional cognitive load for all people, who must first learn how to navigate its specific, often unique, compound UI before they can even consume the content. Users are forced to figure out: Is it swipeable? Do the keyboard arrow keys operate it? How many slides are present? This metadata must be quickly conveyed and understood, and users must be sufficiently motivated to engage beyond the initial view.

Vestibular and Cognitive Barriers

Perhaps the most egregious accessibility violation found in carousels is the use of auto-advance (auto-playing slides). Auto-advancing content creates severe barriers for people with cognitive disabilities, reading difficulties, and attention deficit disorders, who may not have enough time to read the content before it vanishes.

Furthermore, unexpected motion can trigger motion sickness, dizziness, or disorientation for people with vestibular disorders. If a carousel must feature auto-advance, it must be off by default, or provide a highly visible, user-controllable mechanism to pause or stop the motion immediately.

Screen Reader and Keyboard Navigation Nightmares

From an assistive technology standpoint, carousels are notoriously difficult to implement accessibly.

• Focus Traps and Navigation: Keyboard and screen reader users must be able to bypass the carousel entirely without being forced to interact with every single slide or hidden control.
• Hidden Content: Slides that are visually hidden must also be hidden from screen readers (e.g., using aria-hidden="true" or inert), and keyboard focus must not land on links or buttons inside hidden slides.
• Announcements: Developers must carefully consider what is announced by screen readers when the user interacts with the carousel. For example, using an ARIA live region (aria-live="polite") is useful to announce what has changed (e.g., "Slide 2 of 5: Summer Sale"), but it becomes overwhelming and disruptive if it announces the entire verbose contents of the slide on every rotation.
• Single Point Activation: People with motor disabilities may not be able to perform complex gestures such as swiping or dragging with precision. Carousels must provide a single-point method of operation (simple tap or click buttons) to navigate.

Guidelines for Unavoidable Carousels

If carousels are an absolutely unavoidable component mandated by business requirements, design systems must help teams use accessible patterns to mitigate the damage:

1. Never Auto-Advance by Default: Disable auto-play entirely to respect cognitive load and vestibular sensitivities. If it must be featured, ensure it is user-controllable.
2. Predictability: Favor predictable, related information across slides (e.g., shoe colors and product variations) rather than disjointed, surprising content.
3. Set Expectations: Clearly present the total number of slides, current interval position, and visible navigation controls for people with low vision and screen reader users.
4. Provide a Single-Point Method of Operation: Ensure the carousel can be navigated with single taps or clicks, without relying on complex drag-and-swipe gestures.
5. Optimize Announcements: Ensure screen reader announcements are concise, announcing only state changes (like slide title and position) rather than reading out the entire slide content automatically.

---

Conclusion

Building an accessible design system requires the courage to say "no" to patterns that inherently exclude users. By omitting tooltips, custom-styled selects, and auto-playing carousels, we force ourselves to find clearer, more robust ways to present information.

Designing for intersectionality—anticipating overlapping needs such as low vision combined with motor impairments, or hearing loss coupled with cognitive challenges—ensures that our digital platforms work seamlessly for everyone, regardless of the unique combination of needs they bring. Treat your design system like an intuitive product for consuming teams, and inclusion for people with disabilities like a strict requirement, not a bonus feature.

---

References

Cruse, Dale, and Denis Boudreau. Inclusive Design for Accessibility*. Chapter 10: "Foundations of Accessible Design System Patterns."