[MainMenu]: accessibility issues related to the component

[NatalliaAlieva]

Case №1

Description

Part of navigation links are not available when content is zoomed up to 200%

Precondition

Screen Reader is ON or OFF

Steps to Reproduce

1. Open Main Menu component.
2. Set the size of the adaptive panel so that the Main Menu (hamburger) button is displayed and click on it.
3. Zoom in the content to 200% and observe.

Actual Result

"Action items" and "Subscriptions" links are not available when content is zoomed up to 200% and no vertical scroll is provided.

Main.Menu.Part.of.navigation.links.are.not.available.when.content.is.zoomed.up.to.200.mp4

Expected Result

All functionality should be available when content is zoomed up to 200%.
Failed WCAG Checkpoint: 1.4.4 Resize text (Level AA)
https://www.w3.org/WAI/WCAG21/Understanding/resize-text.html

Case №2

Description

State and change of state of "More" button is not announced by screen reader.

Precondition

Screen Reader is ON

Steps to Reproduce

1. Open Main Menu component.
2. Use Tab key to navigate to collapsed "More" button and note the announcement.
3. Press Enter key to expand "More" button and note the announcement.

Actual Result

Current state (collapsed) and change of state (expanded/collapsed) of "More" button is not announced by screen reader.

Main.Menu.State.and.change.of.state.of.More.button.is.not.announced.by.screen.reader.mp4

Expected Result

Current state and change of state should be announced by screen reader.

Recommendation

To indicate the expanded/collapsed state of the button provide aria-expanded="false" attribute when button is collapsed and aria-expanded="true" when button is expanded.
Failed WCAG Checkpoint: 4.1.2 Name, Role, Value (Level A)
https://www.w3.org/WAI/WCAG21/Understanding/name-role-value.html

Note

aria-expanded is present and correctly switches between true and false, but the screen reader still does not announce the state.
This suggests that the issue may not be caused by the ARIA attribute itself, but by how the element or its role is handled by assistive technologies.

[cpoftea]

@NatalliaAlieva about case №2. Your recording shows when you press collapsed "More" button, dropdown shows, but focus persists on "More" button itself. But at latest UUI version focus moves inside that "More" dropdown, so the button state is not reannounced properly (FF/Chrome-based on MacOS tested).

Could you please confirm it works the same as I described in your environment?

[NatalliaAlieva]

@NatalliaAlieva about case №2. Your recording shows when you press collapsed "More" button, dropdown shows, but focus persists on "More" button itself. But at latest UUI version focus moves inside that "More" dropdown, so the button state is not reannounced properly (FF/Chrome-based on MacOS tested).

Could you please confirm it works the same as I described in your environment?

Hi @cpoftea ,

The focus moving to the first item inside the submenu after activating More is expected behavior.
According to ARIA menu interaction patterns:

Enter:
When focus is on a menuitem that has a submenu, opens the submenu and places focus on its first item.
Otherwise, activates the item and closes the menu.

When the submenu is opened in UUI, the ARIA attributes on the "More" button are updated correctly (aria-expanded="true"), which can be verified in the DOM.

At the same time, the expanded state is not announced by the screen reader. This may be related to the focus being immediately moved into the submenu, as a result of which the screen reader announces the newly focused menu item rather than the state change of the trigger element. Such announcement behavior may vary depending on the screen reader and focus handling.

Reference:
https://www.w3.org/WAI/ARIA/apg/patterns/menubar/examples/menubar-navigation/

[JuliaMV]

Case 1 has been released in 6.4.3 - 04.02.2026