The homepage slider is often the first thing a designer adds and the last thing anyone tests. Five slides rotate every four seconds, the arrows are tiny gray chevrons, and the dots at the bottom cannot be reached with the Tab key. For a sighted mouse user it is mildly annoying. For someone using a screen reader, a keyboard or a magnifier, it can be the part of the page that stops them cold.
An accessible carousel is possible, and most of the work is about control: the visitor decides when slides move, can reach every control, and knows what changed. This post covers autoplay, controls, keyboard use, how slides are announced, and the honest question of whether your site needs a slider at all.
Where sliders go wrong for real people
It helps to picture specific visitors before talking about code.
- A screen reader user starts reading slide two. Halfway through the sentence, the slide changes and the text they were hearing is gone.
- Someone with low vision zooms the browser in. The caption on each slide is cut off, and the arrows have slid out of view.
- A keyboard user presses Tab and lands on links inside slides that are not even visible, because the hidden slides are still in the tab order.
- A person with an attention or reading difficulty cannot finish the headline before it moves.
- Someone with a motor impairment tries to hit a dot that is about the size of a grain of rice.
None of these needs an unusual setup. Each one comes from an ordinary theme slider on a standard business homepage, right in the most visible spot on the site.
Autoplay and WCAG 2.2.2 Pause, Stop, Hide
WCAG 2.2.2 Pause, Stop, Hide applies to content that moves automatically, starts on its own, lasts more than five seconds and is shown alongside other content. A rotating homepage slider fits that description. So visitors need some means of halting it.
In practice, that means a visible pause control. Not a pause that only happens while the mouse hovers over the slider, since keyboard and touch users cannot hover, and not a control hidden until focus arrives. A clearly labeled button that says “Pause” and switches to “Play” is the simplest version.
A good setup goes further:
- Stop rotation when anything inside the slider gets keyboard focus, so someone tabbing to a slide link does not lose it.
- Respect the reduced motion setting. Operating systems let people ask for less motion, and the
prefers-reduced-motionmedia query exposes that preference to your CSS and scripts. Turning autoplay off for those visitors is a kind default. - Consider not autoplaying at all. A slider that only moves when someone asks it to avoids most of these issues in one decision.
Fading and sliding transitions are a separate motion question; our post on animation and reduced motion covers parallax and scroll effects in more depth.
Controls an accessible carousel needs
Every carousel needs a few controls: previous, next, pause (if it autoplays), and often a set of slide pickers. Each one should be:
- A real button element. Spans or divs with click events do not receive keyboard focus unless extra work is done, and they do not announce themselves as buttons.
- Named in words. An arrow icon with no text is read as “button” or not at all. “Previous slide” and “Next slide” are clear. Slide pickers can say “Show slide 3 of 5”, or use the slide’s title.
- Visible enough. Thin white arrows over a photo often fail WCAG 1.4.11 Non-text Contrast, which asks for 3:1 against the background. A solid backing circle behind the icon usually fixes it.
- Big enough. Dots and arrows should meet 2.5.8 Target Size (Minimum), at least 24 by 24 CSS pixels or enough space around them. Tiny dots set close together are a common failure.
- Showing focus. A clear outline when the control has keyboard focus, which themes sometimes strip out.
Here is the shape of a basic control set, simplified:
<section aria-roledescription="carousel" aria-label="Featured services">
<button type="button">Pause</button>
<button type="button">Previous slide</button>
<button type="button">Next slide</button>
<div aria-live="off"> ...slides... </div>
</section>Swipe and drag
Many sliders support swiping on phones and dragging with a mouse. That is fine as an extra. Since WCAG 2.2, though, criterion 2.5.7 says anything done by dragging also needs a simple tap or click route, and visible previous and next buttons provide it.
Keyboard behavior and hidden slides
Run this test on your own slider. Press Tab from the top of the page and count the stops until you leave the slider. Then ask: did every stop land on something visible?
A frequent problem is that off-screen slides are moved out of sight with CSS but stay in the tab order. The keyboard user tabs through “Learn more” links on slides they cannot see. The fix is to make inactive slides truly hidden from assistive technology and the tab order, for example with the hidden attribute or inert on slides that are not showing, then reveal them when they become current.
Check the order of controls as well. Pause should come early, ideally before the slides, so someone can stop the motion before reading. WCAG 2.4.3 Focus Order is about this kind of sense in sequence.
Watch for keyboard traps
Some slider scripts capture the arrow keys or the Tab key while focus is inside. If you cannot Tab out of the slider and on to the rest of the page, that is a keyboard trap under 2.1.2 and needs fixing before anything else.
Announcing slides to screen readers
A screen reader user should know they are in a carousel, how many slides there are and which one is showing. Two common tools for this:
- Labels. The whole carousel gets a name, such as “Featured services”, and each slide can be labeled “1 of 5”, “2 of 5” and so on.
- Live regions, used carefully. When a user presses Next, announcing the new slide is helpful. When the slider rotates by itself, announcements every few seconds are noise that drowns out whatever the person was reading. The usual approach is to keep the live region off during autoplay and turn it on when the user is driving.
Images on slides need alt text like any other image. If the slide’s headline is text over a background image, the text itself should be real HTML text, not part of the picture. Text baked into a photo cannot be resized, translated or read aloud.
Getting announcements right takes testing with an actual screen reader. A code scan alone will not tell you whether “slide 3 of 5” is read at the right moment or read four times.
Slider accessibility in WordPress themes and builders
On WordPress, sliders come from three places: slider plugins, page builder carousel widgets, and theme-bundled hero sections. Their accessibility varies widely, and it can change between versions. Before you commit to one, open its demo and do the keyboard test above. Look for a pause button, named arrows and slides you cannot Tab into when hidden.
If you already have a slider in place and it misbehaves in other ways, such as images not loading or layouts breaking, our guide to a WordPress slider that is not working covers the general fixes. For carousels built in a page builder, see our notes on Elementor accessibility, since builder carousel widgets have their own habits.
Whatever tool you use, check slider accessibility again after plugin updates. A new version may change the markup of the controls.
Do you need a slider at all?
This is the question worth asking first. Carousels on business homepages tend to hide their content: whatever sits on slide four is easy to miss entirely. They add script weight, and as our post on how sliders slow down websites explains, they can delay how quickly the page appears.
Some alternatives that do the same job with fewer barriers:
- One strong hero section with a single headline and button.
- A grid of three or four cards, each linking to a service.
- A static testimonial block, or a short list of reviews in plain text.
- A gallery that opens on demand rather than rotating.
If a carousel genuinely suits the content, for example a product gallery where people expect to flip through images, build it well. If it is there because the template had one, removing it is often the simplest accessibility fix on the whole site. For how this fits the rest of the work on a WordPress site, see our guide to making WordPress sites accessible, and for audits, fixes and ongoing checks more broadly, our website accessibility services page has the overview.
Frequently asked questions
Are carousels allowed under WCAG?
Yes. WCAG does not ban sliders. It expects that motion lasting more than five seconds can be paused, that every control works with a keyboard and has a name, that controls have enough contrast and size, and that hidden slides do not trap or confuse keyboard and screen reader users.
Is pausing on mouse hover enough?
No. Hover only helps people using a mouse. Keyboard users, touch screen users and many screen reader users never hover. A visible pause button that anyone can reach is the expected way to meet 2.2.2 Pause, Stop, Hide for an autoplaying slider.
How fast should an accessible carousel rotate?
WCAG sets no rotation speed. What matters is that people can pause or stop it. If you keep autoplay, give each slide enough time to read its text comfortably, stop rotation when anything in the slider has focus, and switch it off for visitors who ask for reduced motion.
Should hero slider text be part of the image?
No. Text inside an image cannot be resized, changes quality when zoomed, is harder to translate and only reaches screen readers through alt text. Put headlines and buttons in real HTML over the image, and check that their contrast against the photo is strong enough.
Sliders are one of the page components we test and fix when working on a WordPress site, along with menus, popups, forms and the theme around them. To have that looked at on yours, see our WordPress accessibility fixes.
Next in this series: Modal Popup Accessibility: Focus, Escape, Return
