[DynamicPage]: A11Y non conforming use of aria-expanded in header element

[aliaksei-sivalobau]

Describe the bug

Component title generates element<header aria-expanded="true"> (probably this is because of capability described in docs "The header works in two modes - expanded and snapped and its behavior can be adjusted with the help of different properties.") DynamicPage

However the use of "aria-expanded" doesn't conform to W3C recommendation. The main spec suggests implicit use of ARIA "banner" role which doesn't make use of "aria-expanded" attribute.

• html-aria/#docconformance
• banner

The issue affects accessibility checkpoint ACC-264.1

Isolated Example

No response

Reproduction steps

Screen flow: Inspect <header> element rendered in example from docs .

Automation (AMP) Test: • Run amp tool [accessibility management platform] • Domain: https://sap.levelaccess.net • Username: your sap email address and the password that you have set • Go to toolbox>download chrome extension • Once it is installed> open the plugin • Login : enter your amp instance to get started • Amp url: sap.levelaccess.net • Username: your sap email address and the password that you have set • Create an asset>create a new report>test current page

Expected Behaviour

When ARIA attributes (state, roles, and properties) are not used correctly assistive technology may not correctly function as expected. Valid ARIA markup should be used.

Screenshots or Videos

UI5 Web Components for React Version

2.10.0

UI5 Web Components Version

2.10.0

Browser

Chrome

Operating System

Windows 11 Enterprise

Additional Context

Initially raised in OMSA application: https://jira.tools.sap/browse/OMS-16433

Relevant log output

Organization

No response

Declaration

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

[Lukas742]

Thanks for reporting! I'll forward this issue to our UI5 Web Components Colleagues as the affected component is developed in their repository.

[kineticjs]

The internal Screen Reader specification suggests to "add aria-expanded=”true/false” to the header element" for DynamicPage. The issue status will be updated after internal consultation.

[kineticjs]

Hi @aliaksei-sivalobau,

So the proposal is to remove the aria-expanded attribute and instead add role="banner", (listed as recommended role for header elements when not nested under certain other elements), correct?

Thank you for proposing an enhancement, but could you elaborate a bit further on the benefit for such a change, given that:

1. The documentation describes the role="banner" as A landmark that contains mostly site-oriented content, rather than page-specific content.

At the same time, we cannot presume that the DynamicPage is the topmost container, e.g. it can be inside a FlexibleColumnLayout, so the default role of its header may not be specific to the entire site, but of the page's content only.

2. After testing the proposed changes with JAWS, I do not detect a difference in the speech output, which for our experts is the final decision mark, given that the currently used aria-expanded attribute is not deprecated.

While your proposal in general makes sense for site-level headers, I need to collect a bit more evidence of its applicability for DynamicPage in particular, before forwarding this enhancement proposal to the DynamicPage team.

Thanks!

[aliaksei-sivalobau]

Hi @kineticjs , not exactly. The aria-expanded attribute is needed but should only be used on interactive elements (e.g., buttons, anchors, or elements with role="button") to indicate their functionality to assistive technologies. The issue is only about the fact that aria-expanded is used on the wrong element (see examples from W3C spec). As for the testing, while JAWS (in particular) may not claim the missuse of this attribute, application still needs to comply with ARIA recommendations (accessibility checkpoint ACC-264.1). In our project (OMSA) QA used accessibility management platform to verify webpage compliance (steps descrived above).

[dimovpetar]

Hello @SAP/ui5-webcomponents-topic-p ,

The element in question

<header class="ui5-dynamic-page-title-header-wrapper" id="ui5wc_5-header" aria-label="Header Expanded" aria-expanded="true"><slot name="titleArea"></slot></header>

indeed uses aria-expanded attribute, which according to MDN, requires role "application", "button", etc.. Seems that this header element doesn't fulfill that requirement. Even more, the attribute seems redundant, because there is a slotted ui5-dynamic-page-title that has proper aria-expanded with role=button element. I have tested here https://sap.github.io/ui5-webcomponents/components/fiori/DynamicPage/#basic-usage.

Best regards, Petar

[NakataCode]

Hi @aliaksei-sivalobau,

As mentioned, our internal accessibility specification suggests using <header role="region" aria-expanded="true/false"> for the header container itself. While this would be technically ARIA-compliant (since region role supports aria-expanded), I have a question:

Would adding role="region" to the header resolve your accessibility compliance concerns (ACC-264.1) and satisfy the requirements?

(Just for clarification - the button with proper role="button" and aria-expanded slotted in ui5-dynamic-page-title is just the overflow button)

Best Regards, Nikola

[aliaksei-sivalobau]

Hi @NakataCode , I don't think setting role="region" will resolve the problem since there's no aria-expanded suport for it.

[github-actions[bot]]

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

[ui5-webcomponents-bot]

:tada: This issue has been resolved in version v2.13.0-rc.1 :tada:

The release is available on v2.13.0-rc.1

Your semantic-release bot :package::rocket: