An accessible WordPress slider needs labelled controls, stable focus, and controlled movement.
Inactive slides must leave the reading and focus order. Autoplay should remain off.
Test every control with keyboards, touch, zoom, and assistive technology.
Question the slider first
A slider hides content behind interaction. Many visitors never reach later slides.
Movement, focus, announcements, and hidden content create separate failure opportunities.
Use one only when its interaction serves a clear visitor need.
Consider a static alternative
A gallery exposes every image. A card grid exposes every destination.
Static content removes rotation timing and hidden focus problems.
It also supports scanning, linking, copying, and browser search more predictably.
Use precise terminology
Interfaces may call these components sliders, carousels, galleries, or content rotators.
Do not confuse them with range inputs. Those sliders select numeric values.
This guide covers rotating groups of slides with previous and next controls.
Know who owns the output
WordPress Core provides no general content-slider block. Plugins usually own the interaction. Our Sliderberg Pro page lists what ours handles.
Your theme, optimisation tools, and custom scripts can change its final behaviour.
Evaluate the published component, not merely its editor settings.
Follow an established pattern
The W3C carousel tutorial covers structure, controls, styling, and scripts.
The ARIA carousel pattern describes expected roles and interactions.
Use native HTML behaviour before adding ARIA. Test the complete implementation.
Label the carousel container
Give the complete component a concise accessible label describing its subject.
Use a region only when the carousel deserves landmark-level importance.
A group can suit secondary content. Avoid flooding landmark navigation.
Use carousel role descriptions carefully
`aria-roledescription=”carousel”` can provide a familiar component description.
Its accessible label should describe content, not repeat the word “carousel.”
Verify announcements across supported screen readers. Custom role descriptions need testing.
Give slides understandable names
Each slide needs enough context when readers encounter it independently.
Position labels like “2 of 5” can communicate place within the set.
Use visible headings when slides contain substantial content. Keep heading levels logical.
Use native previous and next buttons
Native buttons provide keyboard activation and familiar semantics without extra scripting.
Name them “Previous slide” and “Next slide.” Arrow shapes alone are ambiguous.
Keep their names stable. Announce slide changes separately when necessary.
Place the rotation control first
When autoplay exists, place its stop control before other carousel controls.
Keyboard users can then stop movement before entering changing content.
The button name should describe the available action, such as “Stop rotation.”
Keep autoplay off by default
Automatic movement distracts readers and shortens their reading time.
It can move content before keyboard or screen-reader users finish.
A manual carousel still needs accessible controls. It removes one major risk.
Meet movement controls when autoplay remains
The WCAG movement guidance requires control in defined circumstances.
Provide pause, stop, or hide functionality for qualifying nonessential movement.
Do not make the control harder to find than the moving content.
Stop rotation on keyboard focus
Autoplay should stop when keyboard focus enters the carousel.
Do not restart it merely because focus moves within the component.
Restart only after an explicit visitor request. Preserve that choice.
Stop rotation on hover
Pointer hover should pause automatic rotation while users inspect content.
Do not use hover as the only stopping method. Touch lacks persistent hover.
Retain a visible keyboard-operable control for every visitor.
Respect reduced motion preferences
Use `prefers-reduced-motion` to remove or greatly reduce nonessential transitions.
Do not treat this preference as permission for inaccessible autoplay elsewhere.
Test reduced-motion mode with real browsers and operating-system settings.
Control transition speed
Rapid movement can trigger discomfort and obscure changing focus outlines.
Long transitions can make controls feel unresponsive. Prevent overlapping commands.
Use restrained movement and immediate reduced-motion behaviour.
Remove inactive slides from focus
Hidden slides must not contain reachable links, buttons, or form fields.
Off-screen positioning alone does not remove content from keyboard navigation.
Use a tested hiding strategy that affects focus and assistive technology.
Hide inactive slides consistently
Visual hiding, focus management, and accessibility exposure must agree.
`aria-hidden=”true”` alone does not disable descendant controls.
Test the accessibility tree and tab order after every slide change.
Watch cloned slides
Infinite loops often create cloned slides before or after real slides.
Clones can duplicate identifiers, accessible names, links, and headings.
Remove clones from accessibility exposure and focus. Test loop boundaries carefully.
Keep focus stable during changes
Activating Next should usually leave focus on the Next button.
Moving focus into new content can disorient users and interrupt navigation.
Move focus only for a documented interaction requiring that change.
Keep focused controls visible
A moving track must never carry the focused element outside the viewport.
Sticky headers, overlays, and captions must not obscure focused controls.
Test browser zoom and narrow screens. Visible focus needs enough surrounding space.
Use logical tab order
Tab order should follow the component’s meaningful visual and reading order.
Avoid positive `tabindex` values. They create fragile page-wide sequences.
Do not add tab stops to static slides merely for announcement.
Support standard button activation
Previous, next, pause, and picker buttons should work with Enter and Space.
Native buttons already support those keys. Styled links need unnecessary repair work.
Never require arrow-key navigation unless the selected pattern defines it.
Choose slide picker behaviour carefully
Dots can become many repetitive tab stops. This worsens long carousels.
A tab pattern can reduce tab stops but requires complete tab behaviour.
Choose one established pattern. Do not mix keyboard models unpredictably.
Label picker controls meaningfully
“Go to slide 3” is clearer than an unlabelled circular button.
Include a short subject when slides are not obvious from position.
Expose the selected state programmatically and visually.
Avoid excessive controls
Thirty picker buttons create a tedious keyboard and screen-reader journey.
Reduce slide count or use a browsable archive for large collections.
A carousel should not replace usable search, filtering, or pagination.
Announce manual slide changes
Manual changes may need a polite announcement describing the new slide.
Keep announcements concise. Do not repeat every paragraph automatically.
Test whether headings and position labels already provide enough context.
Silence automatic changes
A live region should remain off while automatic rotation continues.
Repeated announcements can interrupt unrelated reading elsewhere on the page.
Enable polite announcements after rotation stops and visitors request changes.
Provide drag alternatives
The WCAG dragging guidance requires a single-pointer alternative in defined cases.
Previous and next buttons provide a straightforward alternative to swiping.
Do not make dragging the only way to reveal slide content.
Keep touch targets usable
Tiny dots are difficult for people with limited dexterity or tremors.
WCAG 2.2 generally sets a 24-by-24 CSS-pixel minimum target.
Exceptions exist, but generous controls usually improve the interface.
Make focus indicators obvious
Every carousel control needs a visible indicator during keyboard focus.
The indicator must remain visible across images, captions, and changing backgrounds.
Do not remove browser outlines without a tested, stronger replacement.
Measure control contrast
Arrow icons, button boundaries, and focus indicators need sufficient non-text contrast.
Text labels need appropriate text contrast. Test every image beneath overlays.
One safe background panel often works better than adaptive guesses.
Avoid colour-only states
A differently coloured dot cannot communicate the current slide alone.
Add programmatic selected state and a distinct visible shape or marker.
Test forced-colours mode. Background images and shadows may disappear.
Write purposeful image alternatives
Informative slide images need concise alternatives matching their current purpose.
Decorative backgrounds should remain silent. Nearby headings may already provide context.
Linked images need names describing their destination or action.
Use slide headings carefully
A page with several sliders can produce a confusing heading outline.
Choose heading levels from the surrounding page structure, not visual size.
Do not hide meaningful headings solely because the design looks crowded.
Use clear slide links
Repeated “Read more” links become ambiguous across several slides.
Include the destination subject within each link name. Keep wording concise.
Do not make the entire slide a hidden overlapping link.
Protect text from image crops
Responsive crops can remove meaningful subjects and weaken contrast behind text.
Keep essential text in real HTML. Avoid embedding it inside images.
Test focal points and overlays at every supported viewport.
Test multiple visible slides
Some carousels show one slide on mobile and several on desktop.
Position labels must match visible groups and navigation increments.
Do not hide partially visible cards from keyboard access unexpectedly.
Test responsive control placement
Controls can overlap text or disappear beyond clipped wrappers on small screens.
Keep them near the content they operate. Preserve logical source order.
Test long translations and enlarged text before accepting icon-only layouts.
Avoid viewport traps
Touch swiping inside a full-width slider can block normal page scrolling.
Respect the dominant scroll direction. Do not capture every pointer movement.
Test trackpads, touchscreens, mouse wheels, and keyboard navigation separately. We took that apart in how to test WordPress blocks with a keyboard.
Preserve content without JavaScript
Core content should remain readable when slider scripts fail.
A vertical list is an acceptable fallback. Empty wrappers are not.
Test blocked scripts and delayed loading. Confirm links remain usable.
Load images without layout shifts
Reserve image dimensions so controls and captions do not jump.
Lazy loading must preserve alternative text and useful fallback content.
Do not preload every hidden image. Large sliders can waste bandwidth.
Do not sacrifice access for performance
Removing hidden slides from initial HTML can delay assistive-technology access.
Dynamic insertion needs correct focus, labels, positions, and announcements.
Measure actual benefit before introducing that additional state management.
Test direct links and browser history
Some sliders change addresses for individual slides. History behaviour must remain predictable.
Back should not cycle through unwanted automatic changes.
Direct links should reveal the intended slide and expose its content.
Audit analytics scripts
Analytics handlers can duplicate activations or delay button responses.
Track manual and automatic impressions distinctly. Never move focus for tracking.
Retest controls after consent and analytics scripts load.
Evaluate the plugin frontend
Build a realistic staging slider with links, captions, and varied image sizes. We cover the method in how to build a useful WordPress staging site.
Inspect rendered roles, names, states, hidden slides, and duplicate identifiers.
Feature checklists cannot replace keyboard and screen-reader testing.
Test plugin settings combinations
Autoplay, looping, dots, thumbnails, and multiple slides change accessibility behaviour.
Test the exact configuration intended for production. Defaults provide weak evidence.
Record required settings so future editors cannot reintroduce known failures.
Test plugin deactivation
Deactivate the slider plugin on staging. Inspect remaining content and links.
Shortcodes or recovery prompts can hide all meaningful slide information.
Keep source images and copy somewhere exportable. Document migration responsibilities.
Test theme and optimisation changes
CSS combination can remove focus styles or alter hidden-slide rules.
Delayed scripts can leave controls visible before they function.
Retest after caching, minification, theme, and major plugin updates.
Use a keyboard-only test
Start before the carousel and move through it using Tab.
Operate every visible control. Confirm inactive content receives no focus.
Continue beyond the component. No carousel may trap keyboard focus.
Use a screen-reader test
Listen for the carousel label, control names, positions, and selected states.
Confirm hidden slides stay silent. Check manual announcements for useful brevity.
Navigate headings and links outside the carousel. Duplicate content should not appear.
Use a touch test
Activate every control with one pointer. Check spacing around neighbouring targets.
Swipe when supported, then use button alternatives. Both paths must agree.
Test screen-reader touch exploration. Visual and accessibility order should align.
Use zoom and reflow tests
Enlarged text can cover images, controls, captions, and picker buttons.
Check horizontal page scrolling and clipped slide content at narrow widths.
Do not truncate essential copy solely to preserve a fixed slide height.
Test production output
Open the anonymous public page after caches and consent layers load.
Repeat keyboard, motion, focus, and announcement tests on delivered assets.
Keep evidence with browser versions, plugin versions, settings, and observed failures.
Assign editorial ownership
Editors should know approved slide counts, settings, and content patterns.
Restrict autoplay and advanced settings when they create known accessibility failures.
Require frontend review before every new slider reaches production.
Know when sliders lose
A static list usually exposes content more reliably than a slider.
That advantage grows with slide count, mixed controls, and critical information.
This is the honest weak case. Choose static presentation unless rotation earns complexity.
Use the accessible slider checklist
- Prove the slider is necessary.
- Label the complete component.
- Label every slide.
- Use native control buttons.
- Keep autoplay off.
- Place rotation control first.
- Stop movement on focus.
- Stop movement on hover.
- Respect reduced motion.
- Hide inactive slides properly.
- Remove hidden focus targets.
- Keep focus stable.
- Announce manual changes carefully.
- Provide swipe alternatives.
- Use generous targets.
- Measure control contrast.
- Test every viewport.
- Test plugin deactivation.
- Verify production output.
Frequently asked questions
Prefer no autoplay. Otherwise provide immediate control and stop rotation during interaction.
No. Inactive slides must not leave hidden interactive elements in focus order.
No. Provide visible single-pointer buttons for previous and next actions.
Usually not. Keep focus on the activated control unless another pattern requires movement.
Usually. Static layouts remove motion, hidden content, and complex focus management.
The verdict
Accessible sliders require disciplined frontend behaviour, not attractive previews. Then compare the $299 lifetime suite when several Pro blocks survive your full accessibility audit.
Leave a Reply