Reported by
Originally surfaced from Kibana accessibility issue elastic/kibana#227773.
Describe the bug
EuiFilterButton treats hasActiveFilters as a fallback source for aria-expanded when it is rendered as a collapsible chevron button:
const isExpanded = isCollapsible && (isSelected ?? hasActiveFilters);
hasActiveFilters is a visual/filter-count state, not the disclosure open state. A closed filter popover can still have active filters, so this can leave the trigger exposed to assistive technology as expanded even when the controlled popover is closed, or cause a missing false-to-true announcement the next time the trigger opens.
Impact and severity
This affects screen reader users of filter-popover triggers. The Kibana report notes VoiceOver/Safari missing the expanded-state announcement for the Security > Rules > Benchmarks filter buttons. This is WCAG Name, Role, Value related behavior.
Environment and versions
- Kibana version: 9.1.0 in the downstream report
- Browser: Safari 18.5
- Screen reader: VoiceOver
- EUI: current
main still has the hasActiveFilters fallback in packages/eui/src/components/filter_group/filter_button.tsx
Minimum reproducible sandbox
A minimal component-level case is a collapsible EuiFilterButton with active filters but no explicit open state:
<EuiFilterButton iconType="chevronSingleDown" hasActiveFilters>
Status
</EuiFilterButton>
The button receives aria-expanded even though no open/closed disclosure state was provided.
To Reproduce
- Render
EuiFilterButton with iconType="chevronSingleDown" and hasActiveFilters.
- Do not pass
isSelected.
- Inspect the rendered button.
- Observe that
aria-expanded is derived from active-filter state.
Expected behavior
For collapsible filter buttons, aria-expanded should follow the actual disclosure state supplied through isSelected. hasActiveFilters should continue to affect only active-filter styling and badge semantics. If isSelected is omitted, EUI should not infer a disclosure state from active filters.
Additional context
I have a small local patch with focused RTL coverage that changes the computed expanded state to use isSelected only for collapsible buttons. Happy to open a PR if this scoping looks right.
Reported by
Originally surfaced from Kibana accessibility issue elastic/kibana#227773.
Describe the bug
EuiFilterButtontreatshasActiveFiltersas a fallback source foraria-expandedwhen it is rendered as a collapsible chevron button:hasActiveFiltersis a visual/filter-count state, not the disclosure open state. A closed filter popover can still have active filters, so this can leave the trigger exposed to assistive technology as expanded even when the controlled popover is closed, or cause a missing false-to-true announcement the next time the trigger opens.Impact and severity
This affects screen reader users of filter-popover triggers. The Kibana report notes VoiceOver/Safari missing the expanded-state announcement for the Security > Rules > Benchmarks filter buttons. This is WCAG Name, Role, Value related behavior.
Environment and versions
mainstill has thehasActiveFiltersfallback inpackages/eui/src/components/filter_group/filter_button.tsxMinimum reproducible sandbox
A minimal component-level case is a collapsible
EuiFilterButtonwith active filters but no explicit open state:The button receives
aria-expandedeven though no open/closed disclosure state was provided.To Reproduce
EuiFilterButtonwithiconType="chevronSingleDown"andhasActiveFilters.isSelected.aria-expandedis derived from active-filter state.Expected behavior
For collapsible filter buttons,
aria-expandedshould follow the actual disclosure state supplied throughisSelected.hasActiveFiltersshould continue to affect only active-filter styling and badge semantics. IfisSelectedis omitted, EUI should not infer a disclosure state from active filters.Additional context
I have a small local patch with focused RTL coverage that changes the computed expanded state to use
isSelectedonly for collapsible buttons. Happy to open a PR if this scoping looks right.