[EuiSelectable] Fix repeated screen reader announcement of results count

[yansavitski]

Summary

• What: Fixed EuiSelectable repeatedly announcing total results count on every arrow key navigation.
• Why: Fixes [EuiSelectable] Remove duplicated state instructions for a11y #9197. Screen readers (NVDA on Windows) announce "X results available" on every option change instead of only when the count actually changes. Related Kibana issue: [AI Connector] (Accessibility): Total number of options announced before each option kibana#199463
• How: Changed listScreenReaderStatus from being passed as a React element (<EuiI18n>) to being passed as a plain string via EuiI18n render prop pattern. React elements create new object references on every render, causing EuiScreenReaderLive's useEffect([children]) to fire on every re-render. Strings are compared by value, so the effect only triggers when the results count actually changes.

API Changes

No API changes.

component / parent	prop / child	change	description
—	—	—	—

Screenshots

N/A — no visual changes, this is a screen reader behavior fix.

Impact Assessment

• 🔴 Breaking changes
• 💅 Visual changes
• 🧪 Test impact — None. All 32 existing tests pass, 14 snapshots match.
• 🔧 Hard to integrate

Impact level: 🟢 None

Release Readiness

• Documentation
• Figma
• Migration guide
• Adoption plan

QA instructions for reviewer

Reproducing with NVDA (Windows)

1. Open the EuiSelectable → With Search story in Storybook
2. Enable NVDA screen reader
3. Focus the search input, then navigate options with arrow keys
4. Before fix: NVDA announces "X results available" before every option
5. After fix: NVDA announces the results count only once when entering the list, and again only if the count changes (e.g. when filtering via search)

Verifying on macOS via DOM inspection

The root cause is that aria-live regions mutate on every arrow key press, which NVDA picks up and announces. This can be verified without NVDA by observing DOM mutations directly. Open the story in an iframe (/iframe.html?id=forms-euiselectable--with-search) and paste in DevTools Console:

const observer = new MutationObserver((mutations) => {
  mutations.forEach((m) => {
    const el = m.target;
    if (el.getAttribute?.('aria-live') || el.closest?.('[aria-live]')) {
      const liveEl = el.closest?.('[aria-live]') || el;
      console.log(
        `[aria-live="${liveEl.getAttribute('aria-live')}"]`,
        `hidden=${liveEl.getAttribute('aria-hidden')}`,
        `text="${liveEl.textContent?.trim().slice(0, 80)}"`
      );
    }
  });
});
observer.observe(document.body, {
  childList: true, subtree: true, characterData: true,
  attributes: true, attributeFilter: ['aria-hidden']
});

• Before fix: Console logs aria-live toggles on every arrow key press
• After fix: No aria-live logs during arrow navigation; logs appear only when typing in search (results count changes)

Checklist before marking Ready for Review

• Filled out all sections above
• QA: Tested with VoiceOver (macOS) and verified aria-live region behavior via MutationObserver
• QA: Tested in Kibana
• Tests: All existing tests pass
• Changelog: Added changelog entry
• Breaking changes

[Copilot]

Pull request overview

This PR updates EuiSelectable’s live screen reader status announcement to avoid repeatedly announcing the total results count during keyboard navigation, addressing #9197 by ensuring EuiScreenReaderLive only re-announces when the count actually changes.

Changes:

• Reworked the results-count live region content from a React element (<EuiI18n />) to an EuiI18n render-prop string to prevent EuiScreenReaderLive’s [children] effect from firing on unrelated re-renders.
• Added an upcoming changelog entry for the accessibility bug fix.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
packages/eui/src/components/selectable/selectable.tsx	Changes the live-region “results available” announcement to pass a stable string instead of a new React element per render.
packages/eui/changelogs/upcoming/9197.md	Documents the EuiSelectable screen reader announcement bug fix.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[JasonStoltz]

Hey @yansavitski. I'm removing the Community Contribution label. We use that for contributions from outside of Elastic. I'm also removing the skip-changelong label, as this is a change and requires a changelog.

[mgadewoll]

Sorry for the delay on this, I had to look at this a bit more, as the duplication in screen readers is not reproducible in EUI, only in Kibana.

That being said, I don't have a clearer answer to why the duplication only happens in Kibana. The most logical explanation imho is that the DOM changes on aria-live in EuiScreenReaderLive are picked up sometimes depending on the time frame in which the DOM change happens, which Kibana might affect differently than on EUI side.

Overall, the proposed solution to stabilize the content passed to EuiScreenReaderLive is correct. If the actual text doesn't change, we don't need to trigger an update in EuiScreenReaderLive.
Generally I'd prefer to memoize the content instead, but that is best done once the component is migrated to a function component as that will make it easier to memoize those contents. So the change to pass string here instead is good enough for now. 👍

[mgadewoll]

🟢 The changes are LGTM and the update works as expected (tested on EUI as well as in Kibana). Thanks for digging into this and contributing to add a solution! 🎉

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 72d2d16
• Documentation website
• Storybook

History

• 💚 Build #3219 succeeded c2034d1
• 💚 Build #3218 succeeded f12572e
• 💚 Build #3210 succeeded a09dc16
• 💚 Build #3208 succeeded 739b373
• 💚 Build #3206 succeeded 1d282c4
• 💚 Build #3129 succeeded 0ac0a05

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 72d2d16

History

• 💚 Build #6243 succeeded f12572e
• 💚 Build #6239 succeeded a09dc16
• 💚 Build #6170 succeeded 0ac0a05