A carousel deliberately hides most of its content behind an interaction, so the question is never "how do I build one" — it is whether the thing you are about to hide can afford to be hidden.
I maintain the carousel this page uses as its worked example, so this is not a drive-by criticism of somebody else's component. It is the argument I make before putting one on a homepage, with the cost read out of the code rather than asserted.
The example is the 3D Carousel bundle in the Paragraphs Bundles suite. Its paragraph_bundle_3d_carousel.info.yml declares core_version_requirement: ^11.3 || ^12 and depends on the parent module plus Paragraphs, Entity Reference Revisions and Field Group. If you want the suite as a whole rather than this one decision inside it, what Paragraphs Bundles ships is the overview.
A correct carousel hides things on purpose
One slide is in the accessibility tree; the rest are not
Read the template, templates/paragraph--3d-carousel-bundle.html.twig. Every slide is emitted inside a loop with two attributes computed from its position: aria-hidden is false for the first slide and true for all the others, and tabindex is 0 for the first and -1 for the others. The JavaScript keeps that honest as the ring turns — updateFocusableElements() walks every link, button, input, textarea and select inside a slide and sets tabindex to -1 whenever that slide is not the active one.
That is the accessible implementation. It is also the entire problem. A screen reader user reaches one slide at a time, and a keyboard user cannot tab to a call-to-action button on slide four without first operating the control that brings slide four forward. If the content you are putting in there has to be found, a carousel is the wrong container — not because it is built badly, but because it is built correctly.
The practical test I use: write down what happens if a visitor never touches the control. If the answer is "they miss the offer", move the offer out.
What the module already handles, so you do not have to
Here is what is genuinely in the code. The outer wrapper carries role="region" with a label; the rotating ring carries role="group" and aria-roledescription="carousel". Each slide gets a visually hidden "Slide N of M" label. The slide counter is a role="status" element with aria-live="polite", which is the correct politeness level for a position announcement — the reasoning is in ARIA live regions in Drupal 11.
The JavaScript adds arrow-key navigation on the ring, pauses autoplay on mouse enter, and — the part most carousels get wrong — checks prefers-reduced-motion and starts paused when the user has asked for reduced motion, leaving the play control available so they can opt in. The play and pause button is only rendered at all when the editor has set a rotation delay above zero, and it maintains aria-pressed. The suite's functional JavaScript test for this bundle asserts the aria-hidden transitions and finishes with an axe accessibility scan of the component.
So the accessibility work is done. Doing it well does not make the component appropriate for content that must be reachable, and that distinction is the whole article.
Layout shift is a setting here, not an accident
Cumulative Layout Shift is where most carousels earn their bad reputation: the box has no height until the script runs, the page reflows, and everything below it jumps.
This bundle avoids that by making the height an editorial choice rather than a runtime measurement. The pb_content_3dcar_lheight field is a list with exactly ten allowed values — 100 through 550 pixels in steps of 50 — and the stylesheet carries a matching class for every one of them, pb-3d-carousel--h100 to pb-3d-carousel--h550. The height is in the CSS that arrives with the page, so the space is reserved before any JavaScript runs.
The lesson generalises past this module. If a component's height is decided by script, it will shift. When you evaluate any carousel, look for where the height comes from before you look at the transitions.
Two things are still yours to get right. The slide field has unlimited cardinality, so nothing stops an editor adding forty slides; and the breakpoint field is a required single-value list, so exactly one of five stylesheets is attached per carousel and you must pick the one that matches where it sits on the page. Getting that pairing right across a site is theming work — what a Drupal themer does covers that side of it.
The first slide is probably your LCP element
Put a carousel at the top of a page and its first slide becomes the largest element in the viewport, which makes it the thing your Largest Contentful Paint score is measuring. That element is now inside a container with a CSS perspective of 40rem and slides carrying transform-style: preserve-3d and a one-second transform transition.
Worse, if the slide image comes from a Drupal image field it is lazy-loaded by default, which is the wrong setting for anything above the fold. That is a separate and very fixable problem, set out in why your hero image is lazy-loaded by default. The combination — a lazy image, inside a transformed container, animating — is how a homepage ends up failing a metric that a single static banner would have passed comfortably.
When a carousel is genuinely the right component
It is not never. The pattern fits when three things are true at once.
- The items are peers. Six photographs of the same building, eight partner logos, a set of testimonials — nothing in the set is more important than the rest.
- Nothing in it is load-bearing. No pricing, no primary call to action, no information a visitor came for.
- The visitor has already arrived with intent. A gallery part-way down a product page is browsing. A carousel as the first thing on a homepage is an interruption competing with itself.
If any one of those is false, the honest alternatives are a grid that shows everything at once, a single decisive banner, or — for a long set of peers — a horizontally scrollable list, which keeps every item in the DOM and in the tab order.
Common questions
How many slides should I use?
Fewer than you want to. Three to six is a set a visitor can hold in their head; beyond that the counter stops meaning anything and later slides are effectively unpublished. The field will let you add forty, which is a reason to decide the number in the design rather than in the editing form.
Does autoplay hurt?
It moves content away from people who read slowly, and it competes with the rest of the page for attention. If you use it, the pause control has to be real — here it only renders when a rotation delay is set, and reduced-motion users start paused by design. Setting the delay to zero is a legitimate configuration, not a failure to configure.
Is the 3D version worse than a flat one?
Not for accessibility; the suite also ships a plain carousel bundle with the same core support range, and both take the same approach to hidden slides. The 3D version costs more in compositing and constrains your slide geometry, so choose it because the effect is wanted, not because it is available.
Will search engines see slides two and beyond?
The markup for every slide is in the initial HTML response, so it is present rather than injected later. How much weight anything behind an interaction carries is a separate question I would not assert an answer to — which is itself a good reason not to put content you need indexed in there.
Where to go next
Take one carousel on your site and list what is inside it. If any item is something you would be unhappy for a visitor to miss, that item belongs on the page instead, and the carousel keeps whatever is left. I have been doing web development since 2005 and I author Drupal modules and themes at drupal.org/u/flashwebcenter, including this one — and it is still the component I most often talk people out of. If you want a second opinion on a specific page, send me the URL, or see Drupal services for the broader front-end work.
