Inclusive Carousels: Why and How to Fix Common Accessibility Issues

Your website is a front door leading visitors into a space that represents your brand and company. And like it or not, web accessibility dictates who gets to enter.

An accessible website is usable by everyone, including people with disabilities. In addition to compliance and moral reasons to ensure this on your company site, there’s also your bottom line: Americans with disabilities represent an estimated $490 billion in disposable income annually.

Millions of people rely on assistive technologies to use the web, a big chunk of everyday visitors. Yet we’ve found an even bigger win-win. Accessibility's net effect makes websites better for all of your visitors…more people to love your company and brand.

The work to achieve compliance may be daunting, but doesn’t have to be. If you’re unsure about your site’s readiness, read our post about fixing key accessibility issues.

An Everyday Inaccessible Website Experience 

Even basic tasks become a frustrating maze of guesswork for a person using assistive tech (screen readers, keyboard navigation, voice control) on an inaccessible website.

People scan headings within page content for structure and meaning. Within the page’s HTML, heading tags (i.e. H1, H2, H3, etc) denote semantic and visual hierarchy. When h tags don’t reflect hierarchy, screen reader users cannot extract a logical story about the page’s purpose.

Lacking semantic structure, page content is interpreted out of order. This results in a non-sensical reading experience.

Calls to action, like a button stating “Sign Up”, lack adequate context. Sign up for what?

Among the biggest culprits that create user confusion and frustration (directly correlating to high bounce rates and lower conversion rates) are interactive elements like carousels (a.k.a. sliders).

Common Carousels Accessibility Issues 

Carousels are flashy, dynamic, and when designed with purpose can support an optimized user experience. But when they’re not, they present all sorts of issues:

Banner Blindness: Carousels add motion to a webpage, and unless done well this can create visual noise leading to “banner blindness” – website visitors skip over them altogether.

Poor Engagement: Data generally shows that carousels have low engagement, begging the question about whether the space they occupy can be better utilized.

Core Web Vitals: Carousels can slow page load times (hurting SEO and UX) due to JS and CSS dependencies, and the need to load many images. 

Mobile UX: Carousels often have poor mobile UX, which frustrates mobile visitors and damages the value of this important source of customers.

Web Accessibility: Serious accessibility issues are common, creating problems for as many as one in four web users in the US.

The most common accessibility barriers baked into poorly implemented sliders are described below. Each is commonly found in real-world audits (including our own) and is a significant barrier to users with disabilities.

Issues are ranked by frequency of occurrence within audits and severity of impact to users. Each issue is presented with a practical, actionable solution that aligns with current best practices (with examples, whenever possible).

No Keyboard Access

Many sliders are not fully operable via keyboard, or worse, they trap focus. Users who navigate by keyboard can’t:

• Tab into or through the carousel
• Activate “Next” or “Previous” buttons, or navigation dots
• Escape the carousel area easily

Solution: Implement interactive controls (next, previous, pause / play buttons) with <button> or <a> elements; ensure logical keyboard focus order and visible focus states.

WCAG Reference: 2.1.1 Keyboard

Auto-Advance with No Controls

Auto-advancing carousels hurt usability by creating:

• Distractions that lead to banner blindness
• Frustration due to content that shifts while users are still reading
• Readability issues for users with cognitive impairments or who use screen readers

Solution: If an auto-advancing behavior is somehow crucial:

• Use aria-label so screen readers can announce each button’s purpose.
• Ensure the buttons are keyboard-focusable and trigger the appropriate JavaScript actions.
• Include a “Pause” button so users have an option to pause auto-rotation.

Here’s an example of a pause button applied on our homepage, which contains an “infinite” carousel of client logos. Note the aria-label element, which contains a clearly stated label that identifies the pause button for people who use screen readers.

<button class="carousel-pause-button" aria-label="Pause infinite carousel" data-carousel-index="0"> content </button>

WCAG reference: 2.2.2 Pause, Stop, Hide

Insufficient Color Contrast

Slide navigation elements or text overlaid on images that have low contrast can cause readability issues for users with visual impairments.

Solution: Ensure that all carousel navigation elements and overlay text meet minimum a 4.5:1 contrast ratio.

You can quickly determine contrast issues with carousel control, headlines, text and other content on your website with a contrast checking tool, such as colorcontrast.cc.

WCAG reference: 1.4.3 Contrast (minimum)

Poor Screen Reader Experience

ARIA attributes help assistive technologies understand the structure, purpose, and state of web elements. When these or semantic structure is missing, screen reader users lose context.

If ARIA attributes are present at all, they’re often misused. This results in:

• No indication of the current slide
• No announcement of content changes
• Redundant or confusing screen reader output

It’s important to give carousel content a semantic structure, and to ensure that its elements contain the correct ARIA attributes. A well-coded carousel uses ARIA to describe the region and its controls clearly, and to politely inform users when content changes.

<section aria-labelledby="featured-content" role="region">

  <h2 id="featured-content">Featured Content</h2>

  <!-- Carousel content here -->

</section>

Implement code in this fashion and screen readers now know that the carousel is a distinct part of the page. It has a name and serves a purpose.

Solution:

• Clearly mark slides with appropriate ARIA roles (e.g. role="group", aria-roledescription="slide")
• Include accurate labels (aria-label, aria-live) to convey slide position/status
• Mark active slides with aria-hidden="false" and hide inactive ones:

<div class="slide" aria-hidden="false">Current slide</div>

<div class="slide" aria-hidden="true">Hidden slide</div>

If slides update automatically, use aria-live="polite" to announce changes without interrupting the user:

<div aria-live="polite">Now showing: Slide 2 of 4</div>

WCAG reference: 1.3.1 Info and Relationships, 4.1.3 Status Messages

Ignoring User Preferences

Some users configure their systems to reduce motion due to motion sickness, cognitive overload, or flashing animations can make sites literally unusable.

Solution: Add the following to rule to your carousel CSS:

@media (prefers-reduced-motion: reduce) {

  .carousel-slide {

    animation: none;

    transition: none;

  }

}

WCAG reference: 2.3.3 Animation from Interactions

Inaccessible Swipe Gestures on Mobile

A Carousel that relies exclusively on swipe gestures for mobile device users disadvantages people who have limited dexterity or motor impairments.

Solution: Provide equivalent accessible controls (buttons for next / previous) in addition to swipe gestures. Ensure that  these elements are clearly labeled and operable with assistive technology.

Accessibility = Inviting, Inclusive, and Responsible

Accessibility design isn’t about making things “perfect”, just usable. It’s about building a space that invites everyone in and ensuring they can find what they need once they’re there.

“Perceivable, Operable, Understandable, Robust. If you understand and follow these principles, you can make inclusive websites.”
- Samuel Proulx on WCAG Principles​

Need help evaluating your site’s accessibility—or rebuilding features like your carousel the right way? Let’s talk.

‍