Description
Caused by elastic/kibana#220028
Problem Statement
We currently don't provide a way to announce content on mount of a component to screen readers. To achieve this for consumers this would require additional markup and handling.
The main limitation to this is that elements with aria-live (and potentially aria-atomic) only announce content on change. This means that the aria-live element has to already be in the DOM to register a change.
The EUI EuiScreenReaderLive component is based on this setup as well. It currently provides functionality to announce content on change but not mount.
There is a need to announce content on mount of a component as well, e.g. for usages of EuiCallOut or EuiToast is shown (e.g. a confirmation or warning) based on a user action
Proposed Solution
The idea to provide a solution to this issue it to enhance EuiScreenReaderLive to conditionally trigger announcements on mount as well by causing an initial state change of the children. This would result in the element being rendered to the DOM and then changed which would trigger an announcement as required. This would enable any passed content being read on mount if needed.
Additionally, considering that EuiCallOut is used as banner/callout we can assume that it should (maybe conditionally) announce its content as well instead of being static content in the DOM. It could be updated to use the enhanced EuiScreenReaderLive component to announce content on mount.
💻 Initial PoC of the change was done here
Value / Impact
Improving content announcements and action feedback for screen reader users. As well providing a centralized way for these kind of announcements and with it fixing A11y audit issues.
Urgency
This is part of addressing Accessibility audit issues. The entry issue on Kibana side is a defect-level-1, meaning a high priority.
Do alternatives or workarounds exist?
Where possible, consumers would currently need to add wrappers with aria-live on their content. While it's a workaround, it's not very scalable across e.g. Kibana and we'd rather not want them to manually handle this in different ways across the codebase.
Description
Caused by elastic/kibana#220028
Problem Statement
We currently don't provide a way to announce content on mount of a component to screen readers. To achieve this for consumers this would require additional markup and handling.
The main limitation to this is that elements with
aria-live(and potentiallyaria-atomic) only announce content on change. This means that thearia-liveelement has to already be in the DOM to register a change.The EUI EuiScreenReaderLive component is based on this setup as well. It currently provides functionality to announce content on change but not mount.
There is a need to announce content on mount of a component as well, e.g. for usages of EuiCallOut or EuiToast is shown (e.g. a confirmation or warning) based on a user action
Proposed Solution
The idea to provide a solution to this issue it to enhance EuiScreenReaderLive to conditionally trigger announcements on mount as well by causing an initial state change of the
children. This would result in the element being rendered to the DOM and then changed which would trigger an announcement as required. This would enable any passed content being read on mount if needed.Additionally, considering that EuiCallOut is used as banner/callout we can assume that it should (maybe conditionally) announce its content as well instead of being static content in the DOM. It could be updated to use the enhanced EuiScreenReaderLive component to announce content on mount.
💻 Initial PoC of the change was done here
Value / Impact
Improving content announcements and action feedback for screen reader users. As well providing a centralized way for these kind of announcements and with it fixing A11y audit issues.
Urgency
This is part of addressing Accessibility audit issues. The entry issue on Kibana side is a defect-level-1, meaning a high priority.
Do alternatives or workarounds exist?
Where possible, consumers would currently need to add wrappers with
aria-liveon their content. While it's a workaround, it's not very scalable across e.g. Kibana and we'd rather not want them to manually handle this in different ways across the codebase.