[EuiSelectableList] `scrollable-region-focusable` axe violation in non-virtualized mode

[justinkambic]

Reported by

@elastic/obs-exploration-team

Describe the bug

EuiSelectableList triggers an axe scrollable-region-focusable violation in non-virtualized mode. The .euiSelectableList__list wrapper <div> has overflow-y: auto applied via the euiYScrollWithShadows() mixin, but is given tabindex="-1" programmatically (via removeScrollableTabStop) and carries no accessible name or role. This makes the scrollable region unreachable by keyboard, violating the axe rule.

The virtualized path already handles this correctly — data-skip-axe="scrollable-region-focusable" is set on the FixedSizeList outer container. The non-virtualized path has no equivalent.

Impact and severity

• Axe severity: Serious
• End-user impact: Keyboard-only users cannot scroll the selectable list container in non-virtualized mode, potentially missing options that are off-screen.
• Workaround: Callers can exclude .euiSelectableList__list from their axe scans, but this papers over the issue rather than fixing it.

Environment and versions

• EUI version: 113
• React version: 18
• Kibana version (if applicable): 9.4.0
• Browser: Chromium (via Playwright)
• Operating System: macOS

Minimum reproducible sandbox

Render an EuiSelectable with fewer items than the virtualization threshold (default: 100) and run axe against it. The EuiSelectable examples on eui.elastic.co should reproduce this directly — open any example with a short list and run axe.run() in the browser console.

To Reproduce

1. Render an EuiSelectable with a small list (fewer than 100 items, so virtualization is not used)
2. Open the breakdown selector dropdown so the selectable list is visible
3. Run axe against the rendered component (e.g. via axe.run() in the console, or via Playwright + @axe-core/playwright)
4. Observe a scrollable-region-focusable violation reported on .euiSelectableList__list

Expected behavior

No scrollable-region-focusable violation. Either:

• The non-virtualized scroll wrapper receives data-skip-axe="scrollable-region-focusable" for consistency with the virtualized path, or
• The scroll wrapper is made genuinely keyboard-accessible by adding tabIndex={0} and an aria-label derived from the parent EuiSelectable's label or a new dedicated prop.

Screenshots (Optional)

Axe violation output from our Playwright a11y test:

Rule: scrollable-region-focusable. Impact: (serious)
Description: Ensure elements that have scrollable content are accessible by keyboard
Help: Scrollable region must have keyboard access
Nodes: 1. Selectors: .euiSelectableList__list

Additional context (Optional)

Relevant source locations:

• Scrollable styles applied: selectable_list.styles.ts:42–49 (euiYScrollWithShadows)
• tabindex="-1" assignment: selectable_list.tsx:222–228 (removeScrollableTabStop)
• Virtualized path axe skip (existing fix): selectable_list.tsx:522
• Non-virtualized render (missing fix): selectable_list.tsx:753–759

[mgadewoll]

Some initial findings/thoughts:

For both virtualized and non-virtualized variants:

• the DOM order is: scrollable container > ul list container
• there is currently no actual scroll accessibility issue for end users, imho. The actual ul list container is focusable and it handles list item navigation on arrow key press, which also scrolls the list based on focused list item. (You can test non-virtualized by adding listProps={{ isVirtualized: false }} and style={{ height: 200 }} on EuiSelectable in the live code examples in the EUI docs and then tab into the rendered EuiSelectable)
• because the ul element is focusable and handles item navigation manually, the outer scroll container is not focusable to prevent duplicate tab stops (to indicate this the custom attribute data-skip-axe was added. This attribute is used as selector on Kibana side to skip elements for the specific axe rule testing (code) but it won't exclude the elements by default when running any axe test as it's not native to axe-core but EUI specific)

For the virtualized variant:

• while this currently passes the custom data-skip-axe onto react-window's FixedSizeList, the component doesn't actually spread any custom attributes (code) meaning this custom attribute isn't actually applied in the DOM. 🫠 The axe test hence fails for both virtualized and non-virtualized (fyi, the default for EuiSelectableList is virtualized)

@justinkambic
Could you provide exact steps what/where you tested so we can reproduce/test against directly?

[justinkambic]

Hi @mgadewoll thanks for reaching out so quickly! I discovered this while writing e2e a11y test for the Metrics in Discover project: elastic/kibana#256822

Specifically, this test is where we have the exclude (links back to this ticket as well): https://github.com/elastic/kibana/pull/256822/changes#diff-dead2a7ad96ce8277d6851587ab268255193c54e19ac76d20060613969c96e7aR149

When I remove that exclude, the test fails.

Could you provide exact steps what/where you tested so we can reproduce/test against directly?

Certainly.

1. Stand up Kibana and ES (I do this with local dev mode but should work on Cloud as well).

I use simian forge to ingest metrics data into Kibana. The command I use:

./forge \
  --dataset hosts \
  --format both \
  --backfill now-1h \
  --interval 10s \
  --count 100 \
  --purge \
  --elasticsearch-url http://localhost:9200

2. You simply go to Discover and set it to "last 30 days", run an ES|QL query like:

TS metrics-*

3. The metrics grid should show up. Expand the breakdown select list, pictured below, and run the Axe testing tool and you'll see it highlight the select as violating a11y standards.