[ui5-button][a11y]: support the aria-pressed property in accessibilityAttributes

[caroline-ferri]

Feature Request Description

Currently there is no way to suggest that a specific button is selected via screenreader. When a button is selected we expect it to be read out as selected. In order to support this, the web component must support a selected state or the aria-pressed property.

Current accessibility attributes : https://sap.github.io/ui5-webcomponents/components/main/Button/#accessibilityattributes

Note: the ToggleButton https://sap.github.io/ui5-webcomponents/components/ToggleButton/ supports this behavior. However, our current use case does not fully fit the Toggle Button's functionality to select/deselect or do/undo with the same button.

Proposed Solution

Add the aria-pressed property to the list of supported accessibility attributes.

Proposed Alternatives

No response

Organization

SFSF

Additional Context

No response

Priority

Medium

Privacy Policy

• [x] I’m not disclosing any internal or sensitive information.

[didip1000]

Hey @caroline-ferri,

Can you please share your use-case for this scenario?

Thanks, Diana

[caroline-ferri]

@didip1000 ,

The scenario is the following:

1. We have a set of buttons that are used to filter certain cards that are available in a carousel
2. The filter buttons are currently standard Button web components
3. The default selected filter is the "All" filter. This is currently conveyed by setting the "All" button to "Emphasized"
4. When a user clicked a different filter button, the previously selected filter will be automatically deselected (the design is set to "Default" and the new button is set to "Emphasized")
5. The user should not be able to "deselect" the selected filter by clicking the filter button again
6. The user can only change the active filter by selecting a new filter button

Given point 5 in the scenario, we can't properly support the ToggleButton since the user should not be able to "deselect" a filter. The user can only "select" a new filter (or select the default All option to remove specific filters). However, to properly convey the selected state to screenreaders, we need to set aria-pressed to true for the selected button.

I've attached some examples of the filter buttons below:

[didip1000]

Hey @caroline-ferri,

Thank you for your answer, my team (@SAP/ui5-webcomponents-topic-b) will discuss the request.

Best, Diana

[didip1000]

Hey @caroline-ferri,

After discussing your feature request, we wanted to suggest an alternative that might work better for your use case. 
Have you tried using the ui5-segmented-button? It's designed for scenarios like yours and offers several benefits:

• Selected State: The ui5-segmented-button allows users to select a single option from a group of options. When a button is selected it will appear as toggled similar to the ui5-toggle-button. By default only one option is selected but there is the option for multiple selection. It also comes with full accessibility support.
• Easy Implementation: ui5-segmented-button handles state management and accessible semantics, so no extra logic is needed to track selections.
• Fiori Compliance: Fiori guidelines recommend ui5-segmented-button for selecting from a small group of options. The Emphasized button type is meant for primary actions and could cause confusion, especially for those using screen readers, since the "emphasized" type is also announced.

Here’s a sample that demonstrates how segmented buttons could cover your use-case.

Please let me know what you think.

Thanks & Best Regards, Diana

[caroline-ferri]

@didip1000 , thank you for the suggestion. We'll update our implementation to use the segmented button. Given such, I'll close this issue.

[github-actions[bot]]

This issue has been closed. To reopen, just leave a comment!

[caroline-ferri]

@didip1000 , after additional consideration I'd like to reopen this issue. I have found some gaps with the segmented button component for the use case discussed. Our current implementation (which uses the ui5-button component) responsively moves the buttons into an overflow menu if the buttons can't fully be displayed when the viewport is resized.

I've created a sample that displays several filters via the ui5-segmented-button (see filter sample). The filter types are added as plain text per the default recommendation. This example supplies 4 filters, however our use case could have fewer/more depending on the user data. This example illustrates the responsive behavior of the button for smaller viewports with several filters. When the button container is small, the button text can be truncated and the buttons become unreadable. This truncation will introduce a new a11y issues on our page. Due to the responsive behavior for the ui5-segmented-button component, we can't adopt it for the discussed use case.

Given such, I'd like to revisit the idea of adding the aria-pressed attribute to the ui5-button component.