Product Sliders: Browsing, Accessibility, and Extraction

A product slider is a horizontally scrollable row of product cards used to expose a small, related set without turning that set into the page’s main catalogue. It should help a shopper continue a defined buying path—such as finding compatible accessories or comparable alternatives—while preserving every item’s identity, order, and facts for people and machines.

Why this element matters

A slider manages attention by showing a few choices at the moment they become relevant. On a product page, a buyer who has understood the main item may welcome compatible accessories. A full grid at that point would compete with the primary purchase; one compact row preserves the original decision while allowing exploration.

That advantage carries a psychological cost: anything beyond the visible edge is easier to overlook. The first card receives more exposure than the seventh, and a clipped final card can look like an error unless the design signals continuation. A slider must therefore contain a secondary, intentionally ordered set. It must not hide a choice the reader needs in order to understand price, safety, compatibility, or the range itself.

Machine extractability is the ability of search engines, assistants, feeds, and content tools to isolate every product and keep its fields attached. A person may swipe to reveal card six; a crawler may never execute that interaction. When later slides arrive only after JavaScript, use display:none, or exist merely as background images, the system sees an incomplete collection. Rendering every card in semantic source order lets a machine recover the same names, URLs, positions, prices, currencies, and availability that a shopper can reach.

Follow the element writing rules for precedence: classify the block by purpose before choosing its appearance. If its job is to expose a secondary product route, this element applies. If its job is to show complete results or enable side-by-side evaluation, the appropriate grid or typed table takes precedence.

When to use it

Use a product slider when all of these conditions hold:

• The set is secondary to the page’s main task.
• The products share one explicit relationship, such as compatible accessories, same-category alternatives, recently viewed items, or an editorial shortlist.
• Four to eight concise cards give useful breadth without creating a hidden catalogue.
• The order can be explained through relevance, compatibility, editorial rank, recency, or another visible rule.
• Each product remains understandable as a compact card and has a canonical destination for full detail.

A slider beats a grid when vertical space is constrained and readers do not need to see every choice simultaneously. It can preserve context on a product detail page, keep a short recommendation set together on mobile, and expose a next route without placing eight full descriptions in the article flow.

Use a grid when the set is the destination. Search results, a product category, a filtered collection, or a collection that must be scanned in full needs visible counts, sorting, filters, pagination, and stable URLs. Use a comparison table when readers must judge the same specifications across options. Use an image gallery when the items are views of one subject rather than separate purchasable products.

Common near misses include a two-item row forced into carousel controls, a 30-product category squeezed into a rail, a hero banner carousel containing promotions instead of products, and a slider used to conceal weak recommendations below the fold. “Recently viewed” is also a conditional near miss: it is useful only when the visitor actually has history, the heading says why those items appear, and an empty state does not fabricate activity.

Ready to Monitor Your AI Visibility?

Track how AI chatbots mention your brand across ChatGPT, Perplexity, and other platforms.

Get Started Contact

Where to place it

Placement should answer a question the reader has just developed. Put compatible accessories after compatibility and included-items information, alternatives after the primary product’s limitations or decision summary, and related products after the category’s main listing rather than before it. In editorial content, place the rail after criteria and evidence, not before readers know why the products qualify.

Keep the heading, relationship statement, item count, controls, and cards in one region. Put a “View all” link beside the heading or after the row when a complete collection exists. The link must lead to a crawlable canonical page, not expand an unbounded client-side rail.

Do not place a slider beside another slider, an auto-rotating banner, a price table, or the page’s primary purchase controls. Adjacent horizontal gestures create ambiguity, while competing prices can make it unclear which offer the main CTA purchases. Do not interrupt procedural steps, a warning, checkout terms, or required legal disclosure with recommendations. Never put essential variants inside a slider if choosing one changes the primary product’s price, availability, or configuration; variants belong with the owning product controls.

On small screens, allow one complete card plus a deliberate glimpse of the next card, or one complete card with an explicit position label. The region may scroll horizontally, but the document itself must not. Preserve a visible path past the slider so a keyboard or touch user is never trapped in repeated horizontal navigation.

Anatomy

1. Section heading: names the set, such as “Compatible accessories,” rather than the generic “You may also like.”
2. Relationship statement: explains why the products qualify and whether the order is editorial, behavioral, or commercial.
3. Item count: states the finite size before interaction, for example “6 products.”
4. Viewport: clips only presentation; it does not remove off-screen cards from the document.
5. Product card: preserves one product’s name, destination, decisive qualifier, and current commercial facts as a single unit.
6. Continuation cue: uses a partial next card, position text, or both; shadow alone is too easy to miss.
7. Previous and next controls: use buttons named for their effect and expose disabled state at the ends.
8. Position indicator: announces a range such as “Products 1–3 of 6,” not a row of unlabeled dots.
9. View-all route: opens the canonical complete collection when one exists.
10. Focus treatment: remains visible on every control and card link without being clipped by the viewport.

Each card follows the product card contract. The slider owns collection meaning and navigation rather than redefining product facts locally.

Stay Updated on AI Visibility Trends

Get the latest insights on AI mentions, brand monitoring, and optimization strategies.

Email address

Subscribe

Design examples

Editorial shortlist: use for four to eight products selected by stated criteria. The order may represent rank only when the page contains the evidence for that rank; otherwise label it “Selected options” and avoid ordinal claims.

Related products: use for same-category or substitute items after the main product has been explained. State the shared property, such as form factor or price band, rather than implying personalization.

Compatible accessories: use when every item has a verified relationship to the owning product. Repeat the compatible model or range in card text; proximity is not a compatibility guarantee.

Behavioral history: use for recently viewed or saved items only when the visitor created that state. Label the basis, preserve recency order, provide removal where appropriate, and do not emit personalized history into shared caches or structured data.

Parameters

An image is conditional because a text-first product card can be complete without one. If used, its file must exist, dimensions must reserve space, and alternative text must match its purpose. If one card displays price or availability, every peer must display an equivalent current field or explicit status.

Syntax and code examples

Portable Markdown directive

:::product-slider{variant=accessories orderedBy=compatibility visibleDesktop=3 visibleMobile=1.1 viewAllLabel="View all accessories" viewAllUrl="/accessories/"}
## Compatible desk accessories

Verified for the Arc 14 laptop; four products.

::item{id=arc-stand name="Arc laptop stand" url="/products/arc-stand/" price="USD 69" availability="in-stock"}
Raises 13–16 inch laptops and leaves the charging ports clear.
::

::item{id=dock-7 name="Dock 7 hub" url="/products/dock-7/" price="USD 89" availability="in-stock"}
Adds seven ports and supports 100 W pass-through charging.
::
:::

Hugo shortcode mapping

{{< product-slider variant="accessories" orderedBy="compatibility" visibleDesktop="3" visibleMobile="1.1" viewAllLabel="View all accessories" viewAllUrl="/accessories/" >}}
## Compatible desk accessories

Verified for the Arc 14 laptop; four products.

{{< product-slide id="arc-stand" name="Arc laptop stand" url="/products/arc-stand/" price="USD 69" availability="in-stock" >}}
Raises 13–16 inch laptops and leaves the charging ports clear.
{{< /product-slide >}}

{{< product-slide id="dock-7" name="Dock 7 hub" url="/products/dock-7/" price="USD 89" availability="in-stock" >}}
Adds seven ports and supports 100 W pass-through charging.
{{< /product-slide >}}
{{< /product-slider >}}

This is the intended adapter specification, not a registered shortcode invocation. It uses named parameters only. Until the adapter exists, implement the collection as semantic HTML or a non-interactive row without inventing an unsupported shortcode.

WordPress block

<!-- wp:amicited/product-slider {"variant":"accessories","orderedBy":"compatibility","visibleDesktop":3,"visibleMobile":1.1,"viewAllLabel":"View all accessories","viewAllUrl":"/accessories/"} -->
  <!-- wp:heading {"level":2} --><h2>Compatible desk accessories</h2><!-- /wp:heading -->
  <!-- wp:paragraph --><p>Verified for the Arc 14 laptop; four products.</p><!-- /wp:paragraph -->
  <!-- wp:amicited/product-slide {"id":"arc-stand","name":"Arc laptop stand","url":"/products/arc-stand/","price":"USD 69","availability":"in-stock","qualifier":"Raises 13–16 inch laptops and leaves the charging ports clear."} /-->
  <!-- wp:amicited/product-slide {"id":"dock-7","name":"Dock 7 hub","url":"/products/dock-7/","price":"USD 89","availability":"in-stock","qualifier":"Adds seven ports and supports 100 W pass-through charging."} /-->
<!-- /wp:amicited/product-slider -->

Examples

Good: compatibility is explicit

Accessories verified for Arc 14 — 4 products
Arc laptop stand — USD 69 — In stock. Fits 13–16 inch laptops; all Arc 14 ports remain reachable.
Dock 7 hub — USD 89 — In stock. Supports the Arc 14 USB-C charging specification and 100 W pass-through.
Quiet key set — USD 74 — Low stock. Connects over Bluetooth; no receiver occupies an Arc 14 port.
Task light Mini — USD 45 — In stock. Uses a separate USB-C power supply; it does not draw power from the laptop.

This succeeds because the relationship is named and verified, every card makes a distinct compatibility statement, commercial fields are parallel, and the finite count is visible. All four items can exist in source order even when only three fit in the viewport.

Bad: hidden recommendations without a basis

You may also like
BESTSELLER — $69 — Shop now
TRENDING — $89 — Shop now
[Three additional cards load after the second swipe.]

This fails because the heading does not explain the relationship, “bestseller” and “trending” have no defined source or period, the currency is inferred, and repeated “Shop now” labels lose product identity out of context. More seriously, three products do not exist until interaction, so a keyboard user, crawler, or failed script receives a different set.

Schema markup and accessibility

An editorial product slider can feed ItemList when its membership and order are meaningful. Use one ListItem per visible product entity, with position, canonical URL, and the product reference. Positions must match DOM and visual order. Do not mark personalized recently viewed history as a public ItemList, because the set is not stable page content.

Each card may feed Product and Offer data only when the visible page supports the same facts. A name and destination do not justify invented price, rating, brand, availability, or review data. Generate visible fields and structured data from the same approved product source, and omit volatile properties that cannot remain synchronized. There is no special carousel schema type.

Use a named <section> or role="region" only when the heading does not already provide sufficient landmark semantics. Represent the collection as a <ul>, <ol>, or equivalent list; each card is one list item. Keep off-screen cards in the DOM and accessibility tree. Horizontal clipping is presentation, whereas display:none, aria-hidden="true", inert, or client-only virtualization makes content unavailable.

Use native buttons for previous and next. Name them “Previous products” and “Next products,” disable them accurately at the ends, and retain focus after movement. Announce “Products 4–6 of 8” in a polite status region without moving focus into the newly exposed card. Arrow keys may be an enhancement, but Tab must reach controls and links normally. Swipe may be supported, but never as the only input.

Do not auto-advance. Respect reduced-motion preferences and use immediate or restrained scrolling. A card link needs a distinct accessible name containing the product name. Prevent duplicate focus targets when both image and title lead to the same URL. At 200% zoom, cards may become a one-card viewport, but text, controls, and focus rings must remain complete and the page must not overflow horizontally.

Writing rules

The writing should make membership defensible before it makes the row attractive.

• A specific heading explains the route. Use 3–10 words: “Compatible Arc 14 accessories” or “Alternatives under USD 100.” Never rely on “More,” “Trending,” or “You may also like” alone.
• One sentence establishes selection. Use 8–30 words to state shared criteria, audience, compatibility, or history source. If rank or popularity determines order, name the metric, market, and period.
• Finite sets remain inspectable. Use 4–8 products normally and no more than 12. Two or three cards should form a static row; larger assortments need a grid and canonical collection route.
• Card names preserve identity. Use the official product name in 1–8 words. Do not replace it with “Best value,” “Our pick,” or a campaign slogan.
• Qualifiers answer one decision question. Use 4–18 words for fit, distinguishing capability, compatibility, or limitation. Avoid generic praise such as “premium quality.”
• Parallel facts support scanning. If one card shows price, currency, availability, rating, or delivery, peers show equivalent fields or explicit unavailable states from the same source and market.
• Order needs an accountable basis. Compatibility order may put the strongest match first; rank requires published criteria; recency reflects the visitor’s history. Paid placement must be disclosed and cannot masquerade as editorial relevance.
• Actions retain context. Use “View Arc laptop stand,” not five instances of “Learn more.” A card CTA opens that product’s canonical detail page unless the action explicitly adds a known variant to a basket.
• Volatile claims need ownership. Prices, stock, delivery, discounts, ratings, and popularity come from approved systems and carry the required freshness behavior. Editorial prose must not hard-code a conflicting value.

Never place long reviews, comparison matrices, variant selectors, quantity controls, checkout terms, testimonials, countdown timers, pop-ups, video players, or required warnings inside a slide. Do not preselect add-ons, add products to a basket merely by navigating, or conceal sponsored ordering. A slider previews routes; the destination or adjacent primary component holds the complete decision.

Post types that use it

The postTypes frontmatter field drives this table. Inclusion means the element is conditional when a compact secondary product set improves the specified page.

QA checklist

• The set is secondary to the page’s main task and has one explicit product relationship.
• A grid or comparison table would not serve the reader’s actual task better.
• The slider contains 4–8 products normally and never exceeds 12.
• The heading, selection basis, item count, controls, position status, and View-all route are visible where applicable.
• Every card has a stable identifier, official name, canonical destination, and decision-relevant qualifier.
• Price, currency, availability, rating, delivery, and promotion fields are parallel and sourced when shown.
• Compatibility, ranking, popularity, personalization, and sponsorship claims disclose their basis.
• DOM order, visual order, announced position, keyboard order, and any ItemList positions match.
• Every product is server-rendered and usable without JavaScript; no later slide depends on interaction or a client request.
• Off-screen cards remain in the accessibility tree and are not hidden, inert, or represented only by background images.
• Previous and next buttons have distinct names, correct disabled states, visible focus, and stable focus after movement.
• Touch swipe and arrow keys are enhancements; standard buttons and Tab navigation provide complete access.
• There is no automatic movement, focus theft, keyboard trap, or page-level horizontal overflow.
• Position changes are announced as text, and color, clipping, shadows, or dots never carry continuation alone.
• Every image path resolves before publication, dimensions reserve space, and alternative text reflects the card’s purpose.
• At 200% zoom and on a narrow screen, one card, its text, its controls, and its focus ring remain complete.
• Structured data repeats visible, current facts and omits personalized history or invented commercial properties.
• The complete collection has a crawlable View-all URL when readers reasonably need to browse beyond the rail.
• Portable Markdown, Hugo, and WordPress representations preserve the same products, order, fields, and fallback.

FAQ

The academy template renders the five reviewed questions stored in [[faq]] frontmatter.