Skip to content

[Enhancement]: Add Screen Reader Announcement On Slide Change #124

@deepakpra

Description

@deepakpra

Feature description

rtCarousel already includes basic accessibility support for the carousel structure, slides, controls, and dots. However, screen readers are not notified when the active slide changes.

When users navigate with previous/next controls or pagination dots, announce the new slide position, for example:

Slide 2 of 5

Problem it solves

This improves the carousel experience for screen reader users by confirming that navigation worked and identifying the newly active slide.

Acceptance criteria:

  • Slide changes via previous/next buttons are announced.
  • Slide changes via dots are announced.
  • Announcement includes current slide number and total slide count.
  • Existing carousel behavior remains unchanged.

Describe alternatives you've considered

Option 1: Add a custom live region using the existing Interactivity API.

  • Add a visually hidden live region inside the carousel.
  • Use role="status", aria-live="polite", and aria-atomic="true".
  • Update the announcement through the existing Interactivity API state when users manually change slides.
  • Pros: self-contained, no new dependency, works with current frontend state.
  • Cons: we maintain the announcement behavior ourselves.

Option 2: Use WordPress wp.a11y.speak().

  • Trigger a screen reader announcement when users manually change slides.
  • Use WordPress's built-in accessibility utility instead of adding a custom live region.
  • Pros: uses WordPress's built-in screen reader announcement helper.
  • Cons: requires adding/enqueueing the wp-a11y dependency for the frontend block script.

Option 3: Use an Embla accessibility plugin.

  • Add a dedicated Embla accessibility plugin, such as @bluecadet/embla-carousel-a11y, to handle slide announcements.
  • Pros: purpose-built for Embla carousel accessibility.
  • Cons: adds a new dependency and may overlap with the carousel's existing WordPress block markup/interactivity.

Option 1 seems like the preferred direction since it is self-contained and fits the current Interactivity API implementation, but feedback on the approach would be helpful before implementation.

Additional context

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions